Социология. Моделирование данных hl. Системы управления базами данных
 Скачать 0.68 Mb.
|
|
2.7.1. Понятие класса Понятие класса является центральным понятием ООП. Класс может быть определен как определенный пользователем инкапсулированный тип объектов произвольной внутренней сложности. Классы играют роль некоторого шаблона для определения набора подобных объектов. Каждый объект обладает своими собственными характеристиками, однако объекты, имеющие одинаковые свойства и ведущие себя сходным образом, могут быть сгруппированы вместе с образованием класса. Атрибуты и связанные с ними методы (операции над атрибутами) определяются один раз для всего класса, а не для каждого объекта в отдельности. Объекты некоторого класса называются его экземплярами. 2.7.2. Инкапсуляция данных Понятие инкапсуляции означает, что объект содержит как структуру данных, так и набор операций, с помощью которым этой структурой можно манипулировать. Инкапсуляция ограничивает область видимости данных, принадлежащих объекту и, следовательно, доступ к ним. В противоположность реляционным БД, где операции над данными (вставка, удаление, модификация) являются общими и могут быть применены к любым объектам (таблицам) БД, в ООБД инкапсулированные данные одного объекта недоступны для методов другого объекта. Доступ к таким данным предоставляется только операциям этого объекта. В идеале для каждого атрибута объекта должна быть определена операция доступа get. Но требования полной инкапсуляции приводят к невозможности выполнения параллельных транзакций и быстрого поиска на основе индексов. Инкапсуляция также приводит к тому, что обеспечение целостности становится задачей каждого объекта в отдельности. Лишь ссылочная целостность может контролироваться системой снаружи. Поэтому требования инкапсуляции объектов в ООБД выполняются только на уровне пользователей, а не системы в целом. Инкапсулированными являются не только данные, но и операции. Только часть операций является доступной снаружи и предоставляет интерфейс объекта. Операции в ООБД состоят из двух частей: подписи (интерфейса), содержащего имя операции и список аргументов, и тела (метода), содержащего собственно имплементацию операции. Такой подход реализует требование независимости программ и операций, поскольку позволяет модифицировать операции объектов, не затрагивая внешние программы, имеющие доступ к этим операциям. 2.7.3. Наследование Некоторые объекты могут иметь подобные, но не идентичные атрибуты и методы. Наследование позволяет определять один класс на основе другого 39 класса, если имеет смысл совместно использовать подобные атрибуты и методы. Класс, от которого производится наследование, называется базовым классом или суперклассом. Производный класс называется подклассом. Подкласс наследует все основные свойства суперкласса и дополнительно определяет свои собственные. Процесс образования суперкласса называется обобщением, а процесс образования подкласса – специализацией. Такая способность к порождению классов от уже существующих делает возможным поступательное наращивание сложности программы и определяет легкость модификации. Наследование существенно сокращает избыточность данных, т.к. общие свойства могут быть легко перенесены в суперклассы. В свою очередь подклассы могут переопределять свойства суперклассов. Возможность переопределения является важной характеристикой наследования, поскольку позволяет легко управлять отдельными классами с минимальным влиянием на остальную часть системы. Переопределение позволяет повторно использовать имя операции в нескольких классах, что дает возможность определять одно и тоже имя для одной и той же операции независима от ее типа. Конкретный тип операции определяется из контекста при выполнении программы. Такое переопределение имени операции называется перегрузкой. 2.7.4. Полиморфизм Переопределение (перегрузка) является частным случаем полиморфизма. Полиморфизм означает способность одного и того же программного кода работать с разнотипными данными. Иначе говоря, для разных классов можно определить функции с одинаковыми именами, а вызов конкретной функции будет определяться типом данных либо из контекста. Полиморфизм позволяет обеспечить динамическое (позднее) связывание объектов, когда тип объекта становиться известным не в процессе написания программы, а во время ее выполнения. 2.7.5. Идентификация объектов в ООБД Для идентификации объектов в объектно-ориентированных моделях данных применяется автоматически генерируемый уникальный идентификатор (OID – Object Identifier), который назначается каждому объекту в момент его создания. Объекты в ООБД могут и не иметь OID, если они не представляют собой некоторой сущности и могут использоваться разными объектами, например числа и другие простые типы данных. Кроме OID для идентификации объектов может также применяться традиционный подход с использованием ключевых атрибутов. OID обладает следующими свойствами: • генерируется СУБД; 40 • уникально обозначает реальный объект и не зависит от значений его атрибутов; • инвариантен. Его нельзя изменить во время всего жизненного цикла программы. После создания объекта его OID не может быть использован повторно ни для какого другого объекта, даже после его удаления. OID также применяется для связывания объектов и обеспечения ссылочной целостности. Бинарные связи чаще всего реализуются на основе инверсных ссылок, т.е. включения OID объектов друг в друга. Инвариантность OID упрощает контроль целостности, исключая каскадное обновление связанных объектов. Применение OID дает неоспоримые преимущества над реляционной системой, где идентификация объекта производится по значению ключа, зачастую надуманного, и который, к тому же, может меняться. Например, в любой момент времени можно удалить некоторый объект и значение его ключа использовать для другого объекта. Также можно отметить следующие достоинства применения OID: • эффективность и быстрота. OID обычно представляет собой указатель на фактический адрес объекта в памяти и поэтому доступ к нему занимает очень мало времени; • независимость от данных. Объект может неоднократно менять свое содержание, но при этом он останется одним и тем же объектом; • невозможность изменения пользователем. Но и в ООМД все еще остается возможность создания двух идентичных копий некоторого объекта, различающихся только OID, и поэтому применение ключевых атрибутов для дополнительной идентификации объектов оправдано. 2.7.6. Обеспечение доступности и перманентности объектов Обеспечение доступности объектов в ООБД производится на основе присвоения уникальных имен (ключей) объектам, поскольку OID объектов скрыты для пользователей. Прямое присвоение имени каждому объекту в отдельности не производится, так как БД может состоять из сотен и тысяч объектов, и наличие большого числа сложных имен может только привести к усложнению доступа. Но так как обычно объектно-ориентированная система построена на основе иерархии контейнеров, где одни объекты по крайней мере концептуально содержатся в других (обычно содержатся не сами объекты, а их глобальные уникальные идентификаторы), то имена назначают только базовым объектам либо даже коллекциям объектов. Тогда по ссылкам (OID) можно легко добраться до необходимого объекта. Такой механизм доступа сильно отличается от применяемого в реляционных 41 системах, где все объекты предполагаются постоянными и доступными через значения их потенциальных ключей. Перманентность объектов, т.е. возможность длительного хранения объектов во внешней памяти, может быть реализована тремя различными способами: созданием контрольных точек, сериализацией и явной подкачкой страниц. В первом способе на диск копируется все адресное пространство программы (или его некоторая часть). В тех случаях, когда копируется все адресное пространство, программу можно вновь запустить с некоторой контрольной точки. Этот подход имеет два серьезных недостатка. Во-первых, контрольная точка может быть использована только той программой, которая ее создала. Во-вторых, на диск копируется множество совершенно ненужной информации. Во втором способе на диск копируется отдельная иерархия контейнеров объектов. Вначале производится обход связанного графа объектов, доступных из выбранного объекта, затем вся эта структура пишется на диск. Но такой подход не позволяет восстанавливать связанные структуры данных, которые совместно используют одну и туже подчиненную структуру, при их раздельной записи, так как подчиненная структура после восстановления уже не будет совместной. К тому же сериализация производится сразу большими блоками, что приводит к неэффективному расходу памяти компьютера при сохранении небольших изменений. Последний подход связан с явным обменом областей оперативной памяти и внешнего устройства. Этот процесс напрямую связан с преобразованием указателей объектов, существующих в оперативной памяти, и указателей на те же объекты в адресном пространстве внешней памяти. Существуют две реализации этого подхода: в первой объект считается перманентным (т.е. сохраняемым) тогда, когда он достижим для перманентного корневого объекта, а во второй он будет перманентным только в том случае, если он явно объявлен перманентным в прикладной программе. В обоих случаях перманентными будут только те объекты, в которых еще на этапе программирования заложена эта возможность. Недостатками такого подхода являются необходимость сборки «мусора» после выполнения программы, так как объект будет перманентным до тех пор, пока не будет явно удален приложением, и необходимость постоянной обработки двух систем указателей. Последний метод можно считать наиболее перспективным, если напрямую включить схемы обеспечения перманентности в базовый язык программирования. 2.7.7. Стандарт ODMG Совместное использование внешними программами объектов, хранящихся в ООБД, может быть осуществлено только при наличии единого стандарта создания, хранения и использования объектов. 42 Фактически даже отсутствие языка запросов типа SQL, являющимся стандартным языком баз данных, может являться серьезной проблемой при использовании ООБД. Растущий интерес к ООБД предопределил появление такого стандарта. Группа ODMG (Object Database Management Group), включающая ряд ведущих производителей программного обеспечения, разработала стандартную объектно-ориентированную модель данных, которая может быть использована в ООБД. Вначале был создан стандарт ODMG-93 или ODMG-1. Затем он перерос в ODMG-2. ODMG-2 состоит из следующих частей: • объектной модели; • языка определения объектов (object definition language – ODL); • объектного языка запросов (object query language – OQL); • расширения ОО языков программирования (C++, Java, Smalltalk, …). Объектная модель и язык определения объектов стандартизирует ключевые слова, типы данных, их конструкторы и т.д., наряду с механизмами идентификации, связывания, именования, обеспечения доступности и перманентности объектов (смотри систему принятых обозначений на рис. 12). К примеру этот стандарт рекомендует применение только инверсных связей на основе OID и вводит такие ключевые слова как attribute, key, relationship, extent и т.д. Объектный язык запросов представ- ляет собой расширение существующих ООЯП. Синтаксис его похож на SQL и дополнен концепциями наследо- вания, инкапсуляции и полиморфизма. Напри- мер, представим опреде- ление двух классов, лежащих в основе структуры данных ООБД некоторого университета: class Person (extent persons, key ssn) { attribute struct Pname {string fname, string mname, string (name} name; attribute string ssn; attribute date birthdate; attribute enum Gender{M, F) sex; 43 Рис. 12 Система принятых обозначений attribute struct Address {short no, string street, short aptno, string city, string state, short zip} address; short age(); }; class Student extends Person(extent students) { attribute string class; attribute Department minors_in; relationship Department majors_in inverse Department::has_majors; relationship set void change_major(in string dname) raises(dname_not_valid); float gpa(); void register(in short secno) raises(section_not_valid); void assign_grade(in short secno; in GradeValue grade) raises(section_not_valid, grade_not_valid); }; и саму структуру (смотри рис. 13) Рис . 13. Структура данных ООБД университета 2.7.8. Выводы ООБД обладают следующими преимуществами: 1. Однозначная идентификация объектов; 2. Расширенные возможности моделирования. Позволяет более точно моделировать реальный мир; 3. Расширяемость; 4. Устранение проблем несоответствия. Программы могут читать объекты напрямую, без промежуточной конвертации; 5. Поддержка эволюции схемы; 44 6. Применимость для разработки сложных специализированных БД. Также можно сформулировать и недостатки, присущие ООБД: 1. Отсутствие универсальной модели данных; 2. Недостаточный опыт эксплуатации и отсутствие стандартов; 3. Сложность; 4. Отсутствие поддержки стандартных видов представлений; 5. Недостаточность средств обеспечения целостности и безопасности информации. Концептуальное различие объектно-ориентированной и реляционной модели заключается в следующем: 1. В типах данных. Простые в РБД и определенные пользователем классы в ООБД; 2. В идентификации объектов. OID в ООБД и потенциальные ключи в РБД; 3. В установлении связей. Инверсные включения OID в ООБД и первичные и внешние ключи в РБД; 4. В возможности наследования в ООБД; 5. В применении и разработке операций. В ООБД операции принадлежат объектам и разрабатываются вместе с ними. В РБД операции являются общедоступными и разрабатываются после определения структуры данных. Примером ООБД можно считать СУБД OpenODB (Hewlett Packard), O2 (Ardent Software) и Object Store (Object Design). 2.8. Объектно-реляционная модель Объектно-реляционные системы получили свое развитие на основе концептуального совпадения назначения и свойств двух фундаментальных понятий в реляционных и объектно-ориентированных баз данных: доменов и классов. Если определить домен немного шире, чем в реляционной модели, а именно как определенный пользователем инкапсулированный тип данных с произвольной внутренней сложностью, то увидим, что домен и класс – это одно и тоже. Следовательно, в ОРБД домены, и соответственно, реляционные атрибуты, могут содержать абсолютно все: массивы, списки, объекты вместе с методами обработки своих данных. Таким образом, реляционная модель данных, где в качестве доменов могут выступать классы, в принципе могла бы решать все задачи, выполняемые в ООБД и невыполняемые в реляционной БД. Для обеспечения функциональности таких систем со стороны объектно-ориентированного подхода требуется поддержка определенных 45 пользователем типов данных произвольной сложности вместе с методами обработки своих данных, а со стороны реляционного подхода требуется, чтобы отношения содержали сами объекты (по крайней мере концептуально), а не ссылки или указатели на них. Примером ОРБД можно считать DB2, Informix, и продукты Oracle 8.x. Контрольные вопросы и задания 1. Назовите основные модели данных. 2. Укажите достоинства и недостатки иерархической модели данных. 3. Укажите достоинства и недостатки сетевой модели данных. 4. Какой вид связи невозможно реализовать в иерархической модели данных. 5. Назовите условия, при соблюдении которых таблицу (реляционная модель данных) можно считать отношением. 6. Дайте определения каждому из следующих понятий реляционной модели данных: отношению, домену, кортежу, степени отношения, кардинальному числу, первичному и внешнему ключу. 7. Укажите различия между потенциальными ключами и первичным ключом отношения. 8. Какие из нижеперечисленных терминов означают одно и тоже понятие в реляционной модели данных: домен, кортеж, отношение, строка, столбец, поле, запись, атрибут. 9. Покажите на простых примерах виды связей между отношениями в реляционной модели данных. Укажите только название отношения, первичные и внешние ключи и по нескольким неключевым атрибутам. 10. Перечислите средства обеспечения ссылочной целостности в реляционной модели данных. 11. Что дает каскадное обновление записей. 12. Что дает каскадное удаление записей. 13. Перечислите отличительные свойства реляционной модели данных. 14. Сформулируйте назначение ключей в реляционной модели данных. 15. Какие задачи решает теория нормализации данных. 16. Опишите проблемы, связанные с наличием повторяющихся данных. 17. Сформулируйте правила нормализации. 18. Дайте определение первой нормальной формы. 19. Дайте определение второй нормальной формы. 46 20. Дайте определение третьей нормальной формы. 21. Зачем необходимо разбивать информацию, хранящуюся в одной таблице, на несколько связанных таблиц в реляционной модели данных. 22. Перечислите основные достоинства и недостатки реляционной модели данных. 23. Чем отличается постреляционная модель данных от реляционной. 24. Сформулируйте назначение и основные принципы построения объектно-ориентированных БД. 25. Перечислите основные достоинства и недостатки многомерной модели данных. 26. На базе относительного сходства какого понятия в реляционной и объектно-ориентированной модели данных получили развитие объектно-реляционные БД. 27. Сформулируйте принципиальные отличия реляционной, объектно- ориентированной и объектно-реляционной модели данных. 28. Чем отличается расширенная ER модель от обычной ER модели. 29. Дайте определение многомерной модели данных. В чем состоит основное отличие многомерной модели от других моделей. 30. Перечислите основные достоинства и недостатки многомерной модели данных. 47 3. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ Все тонкости построения информационной модели некоторой предметной области деятельности человека преследуют одну цель – получить хорошую БД. Давайте поясним термин – хорошая БД и сформулируем требования, которым должна удовлетворять БД: 1. БД должна удовлетворять информационным потребностям пользователей (организаций) и по структуре и содержанию соответствовать решаемым задачам; 2. БД должна обеспечивать получение требуемых данных за приемлемое время, т.е. отвечать требованиям производительности; 3. БД должна легко расширяться при реорганизации предметной области; 4. БД должна легко изменяться при изменении программной и аппаратной среды; 5. Корректные данные, загруженные в БД, должны оставаться корректными (данные должны проверяться на корректность при их вводе). |