Проектирование баз данных

Контрольные вопросы.

1. Опишите основные особенности реляционной модели данных.

2. Перечислите и кратко поясните ключевые понятия реляционной модели.

3. Назовите фундаментальные свойства отношений.

4. Перечислите основные операции реляционной алгебры.

5. Опишите суть реляционного исчисления.

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

Любая предметная область, для которой необходимо спроектировать базу данных, может рассматриваться с разных точек зрения и с разной степенью детализации. При этом можно выявить большое количество сущностей, их характеристик, взаимосвязей между ними и так далее. В этих довольно значительных по объему сведениях может быть сложно разобраться. Кроме того, далеко не всегда для выбранной предметной области существует однозначное описание, имеются документы или специалисты, которые имеют о ней полное представление. Поэтому, описание предметной области – задача, соединяющая в себе как техническое, так и творческое начало. Многие навыки можно приобрести только с опытом, а руководства, которое подошло бы во всех случаях, нет.

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

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

Собственно, из приведенного описания можно выделить три этапа проектирования базы данных. Первый этап – анализ предметной области и построение ее модели. Эту модель называют концептуальной или инфологической, а сам этот этап – этапом концептуального или инфологического моделирования. Работу на этом этапе должны выполнять совместно специалисты по проектированию баз данных и профессионалы в выбранной предметной области, причем ведущая роль должна достаться как раз последним. Именно специалисты, работающие в предметной области, могут дать ее описание, пояснить детали функционирования, выделить важные данные, которые должны отразиться в базе данных, сформулировать ограничения, которым эти данные должны отвечать. Задача специалистов по проектированию БД – зафиксировать эти сведения, используя выбранный метод моделирования.

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

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

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

На выбор СУБД влияют особенности предметной области, которые можно понять из построенной инфологической модели – возможно, для их адекватного отображения в схему данных нужна конкретная модель данных. Также выбор во много определяется проектными решениями для информационной системы в целом (а любая база данных существует не сама по себе), в первую очередь выбранной платформой (ОС, программного окружение, среда разработки и т. д.), архитектурой будущей системы и другими характеристиками. Наконец, важное значение имеют и ожидаемые объемы данных, которые нужно будет хранить и обрабатывать, предполагаемое количество пользователей, требования надежности, безопасности и так далее. И, конечно, финансовые ограничения, как уже было сказано, часто широкая функциональность стоит недешево.

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

Последним этапом проектирования базы данных является этап физического проектирования. На этом этапе решаются вопросы размещения данных, обеспечения доступа к ним пользователей и так далее. В большинстве СУБД база данных состоит более чем из одного файла, и есть возможность разместить эти файлы на разных носителях для достижения более высокой производительности (можно записывать и считывать данные с нескольких носителей одновременно, что повышает общую скорость выполнения операций) и/или более высокой надежности (так, можно создать несколько копий файлов данных, разместить журнал транзакций на отдельном носителе и так далее). Конкретные возможности по физическому проектированию могут заметно отличаться для разных СУБД, так что рассмотреть их в общем не представляется возможным.

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

Так, например, при использовании объектно-ориентированного подхода (что сегодня является наиболее популярным вариантом) модель предметной области будет построена в терминах классов, объектов и различных отношений между ними. Хотя метод проектирования баз данных послужил одним из источников для методов объектно-ориентированного моделирования, полного соответствия между ними нет. Соответственно, процесс даталогического проектирования состоит в том, что объектная модель предметной области преобразуется к схеме базы данных. Для реляционных СУБД это может оказаться достаточно сложной задачей.

Собственно, для преодоления этого разрыва между объектно-ориентированной программной частью и базой данных и разрабатывались объектно-ориентированные СУБД, добавлялись объектно-ориентированные расширения в существующие реляционные системы и так далее. Как уже отмечалось, ООСУБД не заняли большой доли, объектно-ориентированные расширения реляционных СУБД также используются не слишком интенсивно. Зато постепенно оформились так называемые объектно-реляционные отображения (ORM, object-relational mapping), специальные библиотеки, которые автоматически преобразуют модель классов приложения в схему базы данных, а операции с объектами – в запросы на языке SQL. Таких библиотек существует уже довольно много, одна из них, входящая в состав Microsoft Visual Studio.Net будет рассмотрена во второй части настоящего конспекта.