Что такое объект данных

Объект (база данных)

Объект (база данных)

Объекты базы данных содержат всю информацию, о её структуре и данных. Объекты базы данных так же упоминаются, как метаданные. [1]

Сами же объекты в реляционной базе задаются записью (строкой) в таблице. [2]

Содержание

Основные объекты базы данных

Oracle

Основные объекты базы данных в Oracle [3]

Однако как объект базы данных «Пользователь» присутствует не во всех СУБД. Например он присутствyет в Oracle, но отсутствует в IBM и DB2.

Informix

Основные объекты базы данных в Informix [4]

Access

Microsoft SQL Server

Основные объекты базы данных в Microsoft SQL Server

Схема, как объект базы данных

В Oracle [3] и в Microsoft SQL Server 2005 [6] она привязывается пользователю (USER) и является логическим набором объектов базы данных. Схема создается при создании пользователем первого объекта, и все последующие объекты созданные этим пользователем становятся частью этой схемы. Нескольким пользователям можно назначить одну и ту же схему по умолчанию.

В Oracle схема привязывается только к одному пользователю, тогда как в Microsoft SQL Server 2005 несколько пользователей (через группы Windows или роли баз данных) могут владеть одной и той же схемой.

Однако как объект базы данных «Пользователь» присутствует не во всех СУБД. Например он присутствует в Oracle, но отсутствует в IBM и DB2. [3]

Объекты схемы Oracle

Схема может включать другие объекты, принадлежащему этому пользователю:

Существуют и подобъекты схемы, такие как:

Объекты не зависимые от схемы

Существуют объекты не зависимые от схемы

Операции с объектами

Операции с объектами в базе можно проводить с помощью функций языков Data Definition Language. В случае с SQL это функции —

Примечания

Полезное

Смотреть что такое «Объект (база данных)» в других словарях:

БАЗА ДАННЫХ — как объект правовой охраны труда представляет собойобъективную форму представления и организации совокупности данных (на пример, статей, расчетов), систематизированных таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ … Финансовый словарь

База данных — (англ. data base) как объект правовой охраны объективная форма представления и организации совокупности данных (напр., статей, расчетов), систематизированных таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ.… … Энциклопедия права

БАЗА ДАННЫХ — по законодательству РФ об авторском праве объективная форма представления и организации совокупности данных (статей, расчетов и т.д.), систематизированных таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ. Объект… … Юридический словарь

база данных — по законодательству РФ об авторском праве объективная форма представления и организации совокупности данных (статей, расчетов и т.д.), систематизированных таким образом, чтобы эти данные могли быть найдены и обработаны с помощью ЭВМ. Объект… … Большой юридический словарь

Иерархическая база данных — Иерархические базы данных могут быть представлены как дерево, состоящее из объектов различных уровней. Верхний уровень занимает один объект, второй объекты второго уровня и т. д. Между объектами существуют связи, каждый объект… … Википедия

Пространственная база данных — Пространственная база данных база данных (БД), оптимизированная для хранения и выполнения запросов к данным о пространственных объектах, представленных некоторыми абстракциями: точка, линия, полигон и др. (лишь отчасти соответствующих… … Википедия

реляционная база данных — База данных, реализованная в соответствии с реляционной моделью данных. [ГОСТ 20886 85] реляционная БД База данных, логически организованная в виде набора отношений ее компонентов. Характерной особенностью реляционной базы данных является… … Справочник технического переводчика

Реляционная база данных — база данных, построенная на основе реляционной модели. В реляционной базе каждый объект задается записью (строкой) в таблице. Реляционная база создается и затем управляется с помощью реляционной системы управления базами данных. По английски:… … Финансовый словарь

Пространственная база данных (ГИС) — Пространственная база данных база данных (БД), оптимизированная для хранения и выполнения запросов к данным о пространственных объектах, представленных некоторыми абстракциями: точка, линия, полигон и др. (лишь отчасти соответствующих базовым… … Википедия

Объект (значения) — В Викисловаре есть статья «объект» Объект (от лат. objectum предмет) то, на что направлена та или иная деятельность (или то, что создано этой деятельностью); в более широком значении любой предмет вообще. Объект нечто … Википедия

Источник

объект данных

объект данных
Элемент данных, обрабатываемый программой.
[Гипертекстовый энциклопедический словарь по информатике Э. Якубайтиса]
[http://www.morepc.ru/dict/]

Тематики

Смотреть что такое «объект данных» в других словарях:

объект данных (сети и системы связи) — Часть объекта логического узла. Примечание. Объект данных представляет специфическую информацию, например состояние или измерение. С точки зрения объектно ориентированной модели объект данных является экземпляром класса данных. [ГОСТ Р 54325 2011 … Справочник технического переводчика

объект данных процесса — PDO Коммуникационный объект, определяемый коммуникационным PDO параметром и параметром PDO отображения. Относится к не подтверждаемым коммуникационным сервисам и не приводит к избыточности протокола. [http://can… … Справочник технического переводчика

сервисный объект данных — SDO Сервисные объекты данных обеспечивают доступ к записям объектного словаря CANopen. Каждый SDO формируется как минимум двумя CAN сообщениями с различными идентификаторами. SDO – это подтверждаемый коммуникационный сервис типа точка точка.… … Справочник технического переводчика

Объект (база данных) — Объект реляционной базы данных это часть cловаря данных в реляционной базе данных которая может использоваться для хранения информации или обращения к ней. Объекты базы данных содержат всю информацию, о её структуре и данных. Объекты базы данных… … Википедия

ОБЪЕКТ — (от лат. objectum предмет) в самом широком смысле то, на что направлено индивидуальное или коллективное сознание. Когнитивным, или эпистемологическим, О. является все, что воспринимается, воображается, представляется или мыслится; О. может быть… … Философская энциклопедия

Объект Мейола — Галактика … Википедия

объект MIB — Элемент в базе данных, доступный агентам SNMP для управления. Объекты идентифицируются уникальными последовательностями неотрицательных целых чисел и именами. Набор атрибутов, который можно использовать для настройки, управления или анализа… … Справочник технического переводчика

объект управления клиентом — Клиент канала передачи данных, который использует идентификатор клиента 0х00 для отправки полного списка локально зарегистрированных клиентов и их дополнительных расширенных возможностей (МСЭ T H.224). [http://www.iks… … Справочник технического переводчика

объект учета затрат — Функция, организационное подразделение, контракт или другая рабочая единица, для которой требуется организовать ведение данных по затратам и накопление и измерение стоимости процессов, продукции, работ, капитальных проектов и т. п.… … Справочник технического переводчика

объект — 3.14 объект (object): Элемент, который может быть охарактеризован посредством измерения его атрибутов. Источник … Словарь-справочник терминов нормативно-технической документации

Источник

Понятие объекта данных

Классификация БД

По технологии обработки БД делятся на централизованные и распределенные.

Централизованная БД хранится в одной ЭВМ.

Распределенная БД хранится на нескольких ЭВМ.

По способу доступа к данным БД разделяется на БД с локальным и удаленным доступом.

При локальном доступе запрос к данным поступает с того же компьютера, где данные хранятся. При удаленном доступе запрос к данным производится с другого компьютера. Удаленный доступ еще называют сетевым.

Компьютер, на котором данные хранятся, называется сервером. Компьютер, с которого данные запрашиваются, называется рабочей станцией.

Чаще всего применяются централизованные базы данных с удаленным доступом. Для таких систем разработаны две технологии:

При технологии «файл сервер» данные в основном обрабатываются на рабочих станциях, для чего станции запрашивают у сервера необходимые файлы данных.

Сервер только хранит данные и может быть не мощным. Недостатком технологии файл-сервер является большой объем переносимой информации по сети (трафик). Например, для получения списка сотрудников отдела станция запрашивает и получает по сети список сотрудников всей организации. Схема технологии представлена на рис 11.1.

При технологии «клиент-сервер» рабочая станция посылает на сервер текст запроса к данным. Обработку запроса производит сервер, после обработки данные посылаются на рабочую станцию. В большинстве операций обработки (фильтр, обобщение) объем данных сокращается. Поэтому сокращается объем переносимой по сети информации (трафик) сокращается.

При технологии клиент-сервер нужен мощный сервер. Однако нагрузка на сеть гораздо меньше, чем при технологии файл-сервер.

Развитием технологии «клиент-сервер» является технология «тонкий клиент». В этой технологии на сервере проводятся не только стандартные операции обработки данных (сортировка, фильтр, обобщение, поддержка целостности), но и все другие операции обработки. Рабочая станция служит только для приема команд пользователя и для отображения результатов и совершенно не обрабатывает данных. Станции даже могут не иметь жестких дисков.

Объектами хранения в текстовых БД являются тексты. Под текстом понимаются неструктурированные данные, состоящие из слов. Основной целью текстовой БД является хранение, поиск и выдача документов, соответствующих запросу пользователя. Такие документы называются релевантными.

По степени универсальности различают:

— СУБД общего назначения.

Специализированные СУБД ориентированы на какую-либо предметную область и для другой области неприменимы. К таким СУБД, например, можно отнести программы бухгалтерии, банковские системы, расчет смет.

СУБД общего назначения охватывают широкий класс задач. Они обладают языковыми средствами настройки на конкретную область и являются, по сути, инструментальным средством для создания специализированных СУБД.

Из СУБД общего назначения выделяются хранилища данных. Они предназначены только для хранения данных, обеспечения сепаратности, целостности, секретности, синхронизации и защиты от отказов. Они не содержат средств для создания интерфейса пользователя.

Под сущностью понимается предмет, явление, процесс, событие окружающего мира, например склад, выдача зарплаты, приходная накладная. Сущность описывается некоторыми характеристиками.

Атрибут – логически неделимый параметр, характеристика, свойство сущности, способный принимать значение (быть чему то равным).

Объект данных – описание представителя некоторой сущности реального мира, в виде логически связанных атрибутов. Объект данных хранится в БД.

Следующие два положения принимаются в теории БД как аксиома отличия: «Значениями атрибутов один объект данных отличается от другого. Не может быть двух объектов данных, у которых попарно равны значения всех атрибутов.»

Объекты данных могут объединяться в наборы объектов по некоторому общему признаку. Этот общий признак обычно выносится в название набора объектов, например, Начисления, Платежи.

Источник

Объекты против структур данных

В статье, перевод которой предложен ниже, Роберт Мартин вроде как начинает с мыслей, очень похожих на те, что можно увидеть в рассуждениях Егора Бугаенко про ORM, но выводы делает другие. Лично мне подход Егора импонирует, но я считаю, что Мартин подробнее раскрывает тему. Мне кажется, с его мнением стоит познакомиться всем, кто когда-либо задумывался о том, какое место должен занимать ORM и вообще, зачем нужны объекты у которых все поля открыты. Статья написана в жанре «Диалог», где более опытный программист обсуждает проблему с тем, у кого опыта меньше.

Класс это спецификация множества сходных объектов

Объект это набор функций которые производят действия с инкапсулированными данными.

Или лучше сказать, что объект это набор функций, которые производят действия с данными, существование которых подразумевается

В смысле «подразумевается»?

Раз в объекте есть функции, то можно предположить, что там также есть данные, но прямого доступа к данным нет и они вообще не видны снаружи.

Разве данные не находятся в объекте?

Может и находятся, но правила, которое гласит, что они обязательно должны там быть нет. С точки зрения пользователя, объект не более чем набор функций. Данные, с которыми работают эти функции должны существовать, но положение этих данных для пользователя неизвестно.

Хорошо, а что такое структура данных?

Структура данных это набор связанных элементов.

Или, другими словами, структура данных это набор элементов с которыми работают функции, существование которых подразумевается неявно.

Ладно, ладно. Я понимаю. Функции которые работают со структурами данных, внутри этих структур не определены, но из самого существования структуры данных можно сделать вывод, что должно быть что-то, что с ними работает.

Правильно. И что можно отметить по поводу этих двух определений?

Они в некотором смысле являются противоположностями друг друга.

Ух ты! Так выходит что объекты и структуры данных это не одно и то же!

Верно. Структуры данных это DTO.

И таблицы в базах данных это тоже не объекты, правда?

Снова верно. Базы данных содержат структуры данных, а не объекты.

Погоди. Разве ORM не отображает таблицы из БД в объекты?

Конечно нет. Отобразить таблицы БД в объекты нельзя. Таблицы в БД это структуры данных, а не объекты.

Тогда чем занимаются ORM?

Они передают данные из одной структуры в другую.

Получается они не имеют ничего общего с Объектами?

Вообще ничего. Строго говоря, такой штуки как ORM в смысле технологии, отображающей реляционные данные в объекты не существует, потому что отобразить таблицы из БД в объекты нельзя.

Но мне говорили, что ORM собирают бизнес объекты.

Нет, ORM вытаскивают из БД данные, с которыми работают бизнес объекты

Но разве эти структуры данных не попадают в бизнес объекты?

Может и попадают, а может и нет. ORM ничего про это не знает.

Но разница же чисто семантическая.

Да нет. Тут есть далеко идущие следствия.

Например дизайн схемы БД и дизайн бизнес объектов. Бизнес объекты задают бизнес поведение. Схема базы данных задает структуру бизнес данных. Эти структуры ограничены очень разными силами. Структура бизнес данных не обязательно лучшая структура для бизнес поведения.

Ээээ. Это непонятно.

Подумай об этом в таком ключе. Схема данных проектируется не для одного единственного приложения, она предназначена для использования на всём предприятии. Поэтому структура данных это компромисс между несколькими разными приложениями.

Хорошо. А теперь подумай про каждое отдельное приложение. Объектная модель каждого приложения описывает как структурировано поведение приложения. У каждого приложения будет собственная объектная модель, чтобы лучше соответствовать поведению приложения.

Ааа, понятно. Так как схема данных это компромисс между разными приложениями, схема не будет ложиться на объектную модель каждого отдельного приложения.

Правильно! Объекты и Структуры ограничены разными вещами. Они очень редко подходят друг другу. Люди называют это рассогласованием объектно реляционного импеданса

Что-то такое я помню. Но вроде рассогласование импеданса как раз исправили с помощью ORM.

А теперь ты в курсе, что это не так. Рассогласование импеданса между объектами и структурами данных комплиментарный, а не изоморфный.

Они противоположности, а не что-то похожее.

Да, в весьма интересном смысле. Видишь ли, объекты и структуры данных подразумевают наличие диаметрально противоположных управляющих структур.

Подумай о наборе классов, которые реализуют какой-то общий интерфейс. Например, представь себе классы которые представляют двумерные фигуры, в которых есть функции для вычисления площади и периметра фигуры.

Почем фигуры пихают во все примеры код с объектами?

Посмотрим на два разных типа фигур: Квадраты и Круги. Понятно что функции для вычисления площади и периметра этих классов используют разные структуры данных. Также понятно, что эти операции вызываются с использованием динамического полиморфизма.

Помедленнее пожалуйста, ничего не понятно.

Есть две разных функции для вычисления площади, одна для Квадрата, другая для Круга. Когда вызывается функция для вычисления площади конкретного объекта, именно этот объект решает какую конкретно функцию вызвать. Это и называется динамическим полиморфизмом.

Ладно. Конечно. Объект знает как реализованы его методы. Естественно.

Теперь давай превратим эти объекты в структуры данных. Используем Discriminated Unions.

Discriminated Unions. Ну, С++, указатели, ключевое слово union, флаг для определения типа структуры, Discriminated Unions. В нашем случае это просто две разные структуры данных. Одна для Квадрата, а другая для Круга. У Круга есть центральная точка и радиус. И код типа, из которого можно понять, что это Круг.

Поле с код будет enum?

Ну да. А у Квадрата будет верхняя левая точка и длина стороны. И ещё enum для указания типа.

Ладно. Будет две структуры с кодом типа.

Правильно. Теперь посмотрим на функцию для площади. Там наверняка будет switch, правда?

Ну. Конечно, для двух классов. Ветка для Квадрата и для Круга. И для периметра тоже нужен похожий switch.

И опять верно. Теперь подумай об этих двух сценариях. В сценарии с объектами две реализации функций для площади, независимы друг от друга и принадлежат (в некотором смысле) непосредственно типу. Функция для площади Квадрата принадлежит Квадрату, а функция для определения площади Круга принадлежит Кругу.

Ладно, я понимаю к чему ты ведёшь. В сценарии со структурами данных обе реализации функции для площади находятся в одной и той же функции, они не «принадлежат» (что бы это слово не значило) типу.

Дальше лучше. В случае с объектами если нужно добавить тип Треугольник, какой код надо поменять?

Не надо менять вообще ничего. Просто сделать новый класс Треугольник. Хотя нет, наверное надо поправить код, который создаёт объекты.

Правильно. Итак, при добавлении нового типа изменения ничтожны. Теперь положим что надо добавить новую функцию — например функцию для определения центра.

Тогда придётся добавить её во все три типа, Круг, Квадрат и Треугольник.

Хорошо. Получается, что добавить новые функции сложно, потому что придётся сделать изменения в каждом классе.

Но со структурами данных всё иначе. Для того, чтобы добавить Треугольник, придётся изменить каждую функцию чтобы добавить в каждый switch ветки для обработки Треугольника.

Правильно. Добавлять типы сложно, приходится править каждую функцию.

Но для того, чтобы добавить функцию для центра менять ничего не надо.

Ух ты. Получается, что эти два подхода прямо противоположны.

Да. Противоположности. Противоположности в любопытном смысле. То есть, если заранее известно, что нужно добавлять новые функции, удобно использовать структуры данных. Но если заранее знать, что придётся добавлять новые типы, тогда надо использовать классы.

Хорошее наблюдение! Но надо сегодня нам надо подумать о ещё одной штуке. Есть ещё один смысл в котором структуры данных и классы являются противоположностями друг друга. Зависимости.

Да, направление зависимостей в исходном коде.

Ладно, я спрошу. В чём разница?

Посмотрим на случай со структурами. Каждая функция содержит switch который выбирает нужную реализацию на основание кода типа в юнионе.

Да, так и есть. И что?

Посмотрим на вызов функции для площади. Вызывающий код зависит от функции для площади, а функция для площади зависит от каждой конкретной реализации.

А что ты имеешь в виду, когда говоришь «зависит»?

Представь себе, что каждая реализация функции для площади выделена в отдельную функцию. То есть будут функции circleArea, squareArea и triangleArea.

Хорошо, получается что в ветках switch будут просто вызовы этих функций.

Представь себе, что эти функции находятся в разных файлах.

Тогда в файле со switch будет import или use или include для файлов с функциями.

Точно. Это и есть зависимость на уровне исходного кода. Один исходник зависит от другого исходника. Как направлена эта зависимость?

Исходный код со switch зависит от исходного кода в котором находятся реализации.

А как насчёт кода, вызывающего функцию для площади?

Вызывающий код зависит от кода со switch, который зависит от всех реализаций.

Верно. Во всех исходниках стрелка направлена в направлении вызова, от вызывающего кода к реализации. Так что, если ты хочешь сделать малюсенькое изменение в этих реализациях.

Ладно, ладно, я вижу к чему ты клонишь. Изменение в любой из реализаций повлечёт за собой перекомпиляцию всех файлов со switch, а это приведёт к тому, что будет перекомпилировано всё, что вызывает этот switch, например в нашем случае функция для площади.

Да. По крайней мере так будет для языков, которые используют даты изменения файлов для того, чтобы понять что нужно пересобрать.

А это в общем все системы со статической типизацией, да?

Да, а ещё некоторые системы без неё

Это много надо пересобрать.

Ладно, а в случае с классами всё наоборот?

Да, потому что код, вызывающий функцию для площади зависит от интерфейса, и реализация тоже зависит от этого интерфейса.

Понятно. В коде для класса Квадрат будет import или use или include файла с интерфейсом Фигура.

Верно. Стрелка в файлах с реализацией указывает в направлении, противоположном направлению вызова. Она направлена от кода с реализацией к коду с вызовом. По крайней мере так будет для статически типизированных языков. Для динамически типизированных языков код, вызывающий функцию для площади вообще не от чего не зависит, потому что линковка происходит в рантайме.

Ага, понятно. То есть если сделать изменения в одной из реализаций.

Пересобрать и передеплоить нужно только код с этими изменениями.

Это потому что зависимости направлены противоположно направлению вызовов.

Да, мы называем это инверсией зависимостей.

Ладно, давай я суммирую это всё. Классы и структуры данных противоположны друг другу в трёх смыслах.

Да, всё верно. И это должен держать в голове каждый дизайнер и архитектор программного обеспечения.

Источник