информатика зачет. Кодекс 1 Определение понятия информация
 Скачать 124.81 Kb.
|
|
27) Классификация моделей данных. Одними из основополагающих в концепции баз данных являются обобщенные категории «данные» и «модель данных». Понятие «данные» в концепции баз данных — это набор конкретных значений, параметров, характеризующих объект, условие, ситуацию или любые другие факторы. Примеры данных: Петров Николай Степанович, $30 и т. д. Данные не обладают определенной структурой, данные становятся информацией тогда, когда пользователь задает им определенную структуру, то есть осознает их смысловое содержание. Поэтому центральным понятием в области баз данных является понятие модели. Модель данных - это некоторая абстракция, которая, будучи приложима к конкретным данным, позволяет пользователям и разработчикам трактовать их уже как информацию, то есть сведения, содержащие не только данные, но и взаимосвязь между ними. Наибольший интерес вызывают модели данных, используемые на концептуальном уровне. По отношению к ним внешние модели называются подсхемами и используют те же абстрактные категории, что и концептуальные модели данных. Кроме трех рассмотренных уровней абстракции при проектировании БД существует еще один уровень, предшествующий им. Модель этого уровня должна выражать информацию о предметной области в виде, независимом от используемой СУБД. Эти модели называются инфологическими, или семантическими. Инфологические модели данных - отражают в естественной и удобной для разработчиков и других пользователей форме информационно-логический уровень абстрагирования, связанный с фиксацией и описанием объектов предметной области, их свойств и их взаимосвязей. Инфологические модели данных используются на ранних стадиях проектирования для описания структур данных в процессе разработки приложения, а дата-логические модели уже поддерживаются конкретной СУБД. Документальные модели данных - соответствуют представлению о слабоструктурированной информации, ориентированной в основном на свободные форматы документов, текстов на естественном языке. Тезаурусные модели - это модели, которые основаны на принципе организации словарей, содержат определенные языковые конструкции и принципы их взаимодействия в заданной грамматике. Эти модели эффективно используются в системах-переводчиках, особенно многоязыковых переводчиках. Принцип хранения информации в этих системах и подчиняется тезаурусным моделям. Дескрипторные модели - самые простые из документальных моделей, они широко использовались на ранних стадиях использования документальных баз данных. В этих моделях каждому документу соответствовал дескриптор - описатель. Этот дескриптор имел жесткую структуру и описывал документ в соответствии с теми характеристиками, которые требуются для работы с документами в разрабатываемой документальной БД. Например, для БД, содержащей описание патентов, дескриптор содержал название области, к которой относился патент, номер патента, дату выдачи патента и еще ряд ключевых параметров, которые заполнялись для каждого патента. Обработка информации в таких базах данных велась исключительно по дескрипторам, то есть по тем параметрам, которые характеризовали патент, а не по самому тексту патента. 28) Инфологическое моделирование. Инфологическая модель применяется на втором этапе проектирования БД (алгоритмическом), то есть после словесного описания предметной области, то есть после этапа постановки задачи. Зачем нужна инфологическая модель и какую пользу она дает проектировщикам? Еще раз хотим напомнить, что процесс проектирования длительный, он требует обсуждений с заказчиком, со специалистами в предметной области. Наконец, при разработке серьезных корпоративных информационных систем проект базы данных является тем фундаментом, на котором строится вся система в целом, и вопрос о возможном кредитовании проекта часто решается экспертами банка на основании именно грамотно сделанного инфологического проекта БД. Следовательно, инфологическая модель должна включать такое формализованное описание предметной области, которое будет «читабельно» не только для специалистов по базам данных, но и сторонних людей. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно, как говорилось раньше, оно не должно быть привязано к конкретной СУБД. Выбор СУБД — это отдельная задача, для корректного ее решения необходимо иметь проект, который не привязан ни к какой конкретной СУБД. Инфологическое проектирование прежде всего связано с попыткой представления семантики, то есть смыслового содержания, предметной области в модели БД. Модель "cущность—связь" Как любая модель, модель «сущность—связь» имеет несколько базовых понятий, которые образуют исходные кирпичики, из которых строятся уже более сложные объекты по заранее определенным правилам. Эта модель в наибольшей степени согласуется с концепцией объектно-ориентированного проектирования, которая в настоящий момент несомненно является базовой для разработки сложных программных систем, поэтому многие понятия вам могут показаться знакомыми, и если это действительно так, то тем проще вам будет освоить технологию проектирования баз данных, основанную на ER-модели. В основе ER-модели лежат следующие базовые понятия: Сущность, с помощью которой моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов — характеристик, определяющих свойства данного представителя класса. При этом набор атрибутов должен быть таким, чтобы можно было различать конкретные экземпляры сущности. Между сущностями могут быть установлены связи — бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности. Например, если у нас есть связь между сущностью «Студент» и сущностью «Преподаватель» и эта связь — руководство дипломными проектами, то каждый студент имеет только одного руководителя, но один и тот же преподаватель может руководить множеством .студентов-дипломников. Поэтому это будет связь «один-ко-многим» (1:М), один со стороны «Преподаватель» и многие со стороны «Студент» (см. рис. 7.2). Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками. Например, между двумя сущностями «Студент» и «Преподаватель» можно установить две смысловые связи, одна — рассмотренная уже ранее «Дипломное проектирование», а вторая может быть условно названа «Лекции», и она определяет, лекции каких преподавателей слушает данный студент и каким студентам данный преподаватель читает лекции. Ясно, что это связь типа многие-ко-многим. Пример этих связей приведен на рис. 7.3. Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной — если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны. Обязательность связи тоже по-разному обозначается в разных нотациях Кроме того, в ER-модели допускается принцип категоризации сущностей. Это значит, что, как и в объектно-ориентированных языках программирования, вводится понятие подтипа сущности, то«есть сущность может быть представлена в виде двух или более своих подтипов — сущностей, каждая из которых может иметь общие атрибуты и отношения и/или атрибуты и отношения, которые определяются однажды на верхнем уровне и наследуются на нижнем уровне. Все подтипы одной сущности рассматриваются как взаимоисключающие, и при разделении сущности па подтипы она должна быть представлена в виде полного набора взаимоисключающих подтипов. Если на уровне анализа не удается выявить полный Перечень подтипов, то вводится специальный подтип, называемый условно ПРОЧИЕ, который в дальнейшем может быть уточнен. В реальных системах бывает достаточно ввести подтипизацпю на двух-трех уровнях. Сущность, на основе которой строятся подтипы, называется супертипом. Любой экземпляр супертипа должен относиться к конкретному подтипу. Для графического изображения принципа категоризации или типизации сущности вводится специальный графический элемент, называемый узел-дискриминатор, в нотации POWER DESIGNER он изображается в виде полукруга, выпуклой стороной обращенного к суперсущности. Эта сторона соединяется направленной стрелкой с суперсущностью, а к диаметру этого круга стрелками подсоединяются подтипы данной сущности (см. рис. 7.5). Между сущностями «Книги» и «Экземпляры» существует связь «один-ко-многим» (1:М), обязательная с двух сторон. Чем определяется данный тип связи? Мы можем предположить, что каждая книга может присутствовать в библиотеке в нескольких экземплярах, поэтому связь «один-ко-многим». При этом если в библиотеке нет ни одного экземпляра дайной книги, то мы не будем хранить ее описание, поэтому если книга описана в сущности «Книги», то по крайней мере один экземпляр этой книги присутствует в библиотеке. Это означает, что со стороны книги связь обязательная. Что касается сущности «Экземпляры», то не может существовать в библиотеке ни одного экземпляра, который бы не относился к конкретной книге, поэтому и со стороны «Экземпляры» связь тоже обязательная. Переход к реляционной модели данных Инфологическая модель используется на ранних стадиях разработки проекта. Если понимать язык условных обозначений, которые соответствуют категориям ER-модели, то ее можно легко «читать», следовательно, она доступна для анализа программистам-разработчикам, которые будут разрабатывать отдельные приложения. Она имеет однозначную интерпретацию, в отличие от некоторых предложений естественного языка, и поэтому здесь не может быть никакого недопонимания со стороны разработчиков. Все специалисты всегда предпочитают выражать свои мысли на некотором формальном языке, который обеспечивает однозначную их трактовку. Таким языком для программистов раньше был язык алгоритмов. Любой алгоритм имел однозначную интерпретацию. Он мог быть реализован на разных языках программирования, но сам алгоритм был и оставался одним и тем же. В первые годы развития вычислительной техники широко издавались сборники алгоритмов для широко распространенных математических задач. Эти сборники программистами прочитывались как увлекательные детективные романы, и они все настоящим программистам были понятны, хотя специалисты других профилей смотрели на эти сборники как на издания на иностранных, неведомых им, языках. Для описания алгоритмов могли использоваться разные формализмы. Одним из таких формализмов был метаязык, в котором использовались слова на естественном языке и каждый мог прочесть эти слова, но смысл самого алгоритма мог понять только тот, кто владел знаниями трактовки алгоритмов. Рассмотрим правила преобразования ER-модели в реляционную. 1) Каждой сущности ставится в соответствие отношение реляционной модели данных. При этом имена сущности и отношения могут быть различными, потому что на имена сущностей могут не накладываться дополнительные синтаксические ограничения, кроме уникальности имени в рамках модели. 2) Каждый атрибут сущности становится атрибутом соответствующего отношения. Переименование атрибутов должно происходить в соответствии с теми же правилами, что и переименование отношений в п.1. Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута (то есть допустимость или недопустимость MULL значений для него). 3) Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности 4) В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY). 5)Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL). При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений (признак NOT NULL). 6) Для отражения категоризации сущностей при переходе к реляционной модели возможны несколько вариантов представления. Возможно создать только одно отношение для всех подтипов одного супертипа. В него включают все атрибуты всех подтипов. Однако тогда для ряда экземпляров ряд атрибутов не будет иметь смысла. И даже если они будут иметь неопределенные значения, то потребуются дополнительные правила различения одних подтипов от других. Достоинством такого представления является то, что создается всего одно отношение. 7) При втором способе для каждого подтипа и для супертипа создаются свои отдельные отношения. Недостатком такого способа представления является то, что создается много отношений, однако достоинств у такого способа больше, так как вы работаете только со значимыми атрибутами подтипа. Кроме того, для возможности переходов к подтипам от супертипа необходимо в супертип включить идентификатор связи. 29) Иерархическая модель данных. Иерархическая модель данных — логическая модель данных в виде древовидной структуры, представляющая собой совокупность элементов, расположенных в порядке их подчинения от общего к частному. В иерархических моделях основная структура представления данных имеет форму дерева. На самом высшем (первом) уровне иерархии находится только одна вершина, которая называется корнем дерева. Эта вершина имеет связи с вершинами второго уровня, вершины второго уровня имеют связи с вершинами третьего уровня и т.д. Связи между вершинами одного уровня отсутствуют. Следовательно, данные в иерархической структуре не равноправны – одни жестко подчинены другим. Доступ к информации возможен только по вертикальной схеме, начиная с корня, так как каждый элемент связан только с одним элементом на верхнем уровне и с одним или несколькими на низком. Содержание 1 Основные понятия применяемые в иерархической модели данных 2 Сущность иерархической модели данных 3 Достоинства и недостатки 4 Операции над иерархически организованными данными 5 См. также 6 Источники 7 Ссылки Основные понятия применяемые в иерархической модели данных Атрибут (элемент данных,поле) - определяется как наименьшая неделимая единица данных, доступная пользователю.. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем. Запись (сегмент) - именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип сегмента — это поименованная совокупность входящих в него атрибутов.. Экземпляр записи - конкретная запись с конкретным значением элементов Групповое отношение - иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) - подчиненными. Иерархическая база данных может хранить только такие древовидные структуры. Сущность иерархической модели данных В целом тип «дерево» представляет собой иерархически организованный набор типов «запись». Иерархическая БД представляет собой упорядоченную совокупность экземпляров данных типа «дерево» (деревьев), содержащих экземпляры типа «запись» (записи). Поля записей хранят собственно числовые или символьные значения, составляющие основное содержание БД. Обход всех элементов иерархической БД обычно производится сверху вниз и слева направо. Достоинства и недостатки: Основными достоинствами иерархической модели данных являются: 1) эффективное использование памяти ЭВМ; 2) высокая скорость выполнения основных операций над данными; 3) удобство работы с иерархически упорядоченной информацией; 4) простота при работе с небольшим объемом данных так как, иерархический принцип соподчиненности понятий является естественным для многих задач. К недостаткам иерархической модели представления данных относятся: 1) громоздкость такой модели для обработки информации с достаточно сложными логическими связями; 2) трудность в понимании ее функционирования обычным пользователем. 3) трудность в применении к данным со сложной внутренней взаимосвязью 4) исключительно навигационный принцип доступа к данным 30) Сетевая модель данных. Сетевая модель данных — логическая модель данных, являющаяся расширением иерархического подхода, строгая математическая теория, описывающая структурный аспект, аспект целостности и аспект обработки данных в сетевых базах данных[1]. Сетевая модель представляет собой структуру, у которой любой элемент может быть связан с любым другим элементом.Сетевая база данных состоит из наборов записей, которые связаны между собой так, что записи могут содержать явные ссылки на другие наборы записей. Тем самым наборы записей образуют сеть. Связи между записями могут быть произвольными, и эти связи явно присутствуют и хранятся в базе данных. . Содержание 1 История 2 Основные понятия используемые в сетевой модели данных 3 Особенности сетевой модели данных 4 Управление сетевыми данными 4.1 Навигационные операции с данными 4.2 Операции модификации данных 5 См. также 6 Источники 7 Ссылки История Сетевая модель была одним из первых подходов, использовавшимся при создании баз данных в конце 50-х — начале 60-х годов. Исторически на разработку этого стандарта большое влияние оказал американский ученый Ч.Бахман. Идеи Бахмана послужили основой для разработки стандартной сетевой модели под эгидой организации CODASYL. После публикации отчетов рабочей группы этой организации в 1969, 1971 и 1973 годах многие компании привели свои сетевые базы данных более-менее в соответствие со стандартами CODASYL. До середины 70-х годов главным конкурентом сетевых баз данных была иерархическая модель данных, представленная ведущим продуктом компании IBM в области баз данных — IBM IMS. В конце 60-х годов Эдгаром Коддом была предложена реляционная модель данных и после долгих и упорных споров с Бахманом реляционная модель приобрела большую популярность и теперь является доминирующей на рынке СУБД. Основные понятия используемые в сетевой модели данных Элемент данных – минимальная информационная единица доступная пользователю. Агрегат данных – это именованная совокупность данных внутри одной записи. Имя агрегата используется для его идентификации в схеме структуры данного более высокого уровня. Агрегат данных может быть простым, если состоит только из элементов данных, и составным, если включает в свой состав другие агрегаты. Запись - это конечный уровень обобщения данных. Иными словами, запись - это агрегат, который не входит в состав никакого другого агрегата и может иметь сложную иерархическую структуру, поскольку допускается многократное применение агрегации. Имя записи используется для идентификации типа записи в схемах типов структур более высокого уровня. Тип записей – это совокупность логически связанных экземпляров записей. Тип записей представляет некоторый класс реального мира. Набор - именованная двухуровневая иерархическая структура, которая содержит запись владельца и запись (или записи) членов. Наборы отражают связи «один ко многим» и «один к одному» между двумя типами записей. Особенности сетевой модели данных Связи в сетевой модели данных осуществляются наборами, которые реализуются с помощью указателей. Сетевая модель данных являются особым витком в развитии иерархической модели данных, их основным отличием является то, что в сетевых моделях данных имеются указатели в обоих направлениях, которые соединяют родственную информацию. Сетевая модель данных предпологает наличие в ней произвольного количества записей и наборов в том числе их различных типов. Связь между двумя записями может выражаться произвольным количеством наборов. В любом наборе может быть только один владелец. Тип записи может быть владельцем в одних типах наборов и членом в других типах наборов, а также не входить ни в какой тип наборов. Допускается добавление новой записи в качестве экземпляра владельца, если экземпляр-член отсутствует. При удалении записи-владельца удаляются соответствующие указатели на экземпляры-члены, но сами записи-члены не уничтожаются (сингулярный набор). 31) Реляционная БД, история появления, принципы организации данных, достоинства и недостатки. Реляционная модель данных. Элементы реляционной модели. Реляционная модель данных – логическая модель данных. Впервые была предложена британским учёным сотрудником компании IBM Эдгаром Франком Коддом (E. F. Codd) в 1970 году в статье "A Relational Model of Data for Large Shared Data Banks" (русский перевод статьи, в которой она впервые описана, опубликован в журнале "СУБД" N 1 за 1995 г.). В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД. В реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. В упомянутой статье Е.Ф. Кодда утверждается, что "реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления". Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название "реляционная" происходит от английского relation – "отношение"). В состав реляционной модели данных обычно включают теорию нормализации. Состав реляционной модели данных Кристофер Дейт определил три составные части реляционной модели данных: структурная манипуляционная целостная Структурная часть модели определяет, что единственной структурой данных является нормализованное n-арное отношение. Отношения удобно представлять в форме таблиц, где каждая строка есть кортеж, а каждый столбец – атрибут, определенный на некотором домене. Данный неформальный подход к понятию отношения дает более привычную для разработчиков и пользователей форму представления, где реляционная база данных представляет собой конечный набор таблиц. Манипуляционная часть модели определяет два фундаментальных механизма манипулирования данными – реляционная алгебра и реляционное исчисление. Основной функцией манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка реляционных БД: язык называется реляционным, если он обладает не меньшей выразительностью и мощностью, чем реляционная алгебра или реляционное исчисление. Целостная часть модели определяет требования целостности сущностей и целостности ссылок. Первое требование состоит в том, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным ключом. Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать). Структура реляционной модели данных Можно провести аналогию между элементами реляционной модели данных и элементами модели "сущность-связь". Реляционные отношения соответствуют наборам сущностей, а кортежи – сущностям. Поэтому, также как и в модели "сущность-связь" столбцы в таблице, представляющей реляционное отношение, называют атрибутами. Основные компоненты реляционного отношения Каждый атрибут определен на домене, поэтому домен можно рассматривать как множество допустимых значений данного атрибута. Несколько атрибутов одного отношения и даже атрибуты разных отношений могут быть определены на одном и том же домене. В примере, показанном на рисунке, атрибуты "Оклад" и "Премия" определены на домене "Деньги". Поэтому, понятие домена имеет семантическую нагрузку: данные можно считать сравнимыми только тогда, когда они относятся к одному домену. Таким образом, в рассматриваемом нами примере сравнение атрибутов "Табельный номер" и "Оклад" является семантически некорректным, хотя они и содержат данные одного типа. Именованное множество пар "имя атрибута – имя домена" называется схемой отношения. Мощность этого множества - называют степенью или "арностью" отношения. Набор именованных схем отношений представляет из себя схему базы данных. Атрибут, значение которого однозначно идентифицирует кортежи, называется ключевым (или просто ключом). В нашем случае ключом является атрибут "Табельный номер", поскольку его значение уникально для каждого работника предприятия. Если кортежи идентифицируются только сцеплением значений нескольких атрибутов, то говорят, что отношение имеет составной ключ. Отношение может содержать несколько ключей. Всегда один из ключей объявляется первичным, его значения не могут обновляться. Все остальные ключи отношения называются возможными ключами. Применение реляционной модели данных Пример базы данных, содержащей сведения о подразделениях предприятия и работающих в них сотрудниках, применительно к реляционной модели будет иметь вид: База данных о подразделениях и сотрудниках предприятия Например, связь между отношениями ОТДЕЛ и СОТРУДНИК создается путем копирования первичного ключа "Номер_отдела" из первого отношения во второе. Таким образом: для того, чтобы получить список работников данного подразделения, необходимо: из таблицы ОТДЕЛ установить значение атрибута "Номер_отдела", соответствующее данному "Наименованию_отдела" выбрать из таблицы СОТРУДНИК все записи, значение атрибута "Номер_отдела" которых равно полученному на предыдущем шаге для того, чтобы узнать в каком отделе работает сотрудник, нужно выполнить обратную операцию: определяем "Номер_отдела" из таблицы СОТРУДНИК по полученному значению находим запись в таблице ОТДЕЛ Атрибуты, представляющие собой копии ключей других отношений, называются внешними ключами. Достоинства реляционной модели: простота и доступность для понимания пользователем. Единственной используемой информационной конструкцией является "таблица"; строгие правила проектирования, базирующиеся на математическом аппарате; полная независимость данных. Изменения в прикладной программе при изменении реляционной БД минимальны; для организации запросов и написания прикладного ПО нет необходимости знать конкретную организацию БД во внешней памяти. Недостатки реляционной модели: далеко не всегда предметная область может быть представлена в виде "таблиц"; в результате логического проектирования появляется множество "таблиц". Это приводит к трудности понимания структуры данных; БД занимает относительно много внешней памяти; относительно низкая скорость доступа к данным. Историю развития баз данных можно разделить на четыре периода. 1. Период становления – начало 60-х - начало 70-х гг. В этот период появляется сам термин «база данных» и создается несколько первоначальных систем. Основой появления баз данных явилось предложение конца 50-х годов использовать файлы для хранения исходных данных. Основное требование к таким файловым системам – быть совместно используемым хранилищем данных. В последующем стало очевидным, что совместно используемые данные, должны обладать специфическими свойствами, в частности: независимость данных, отсутствие дублирования и противоречивости, контроль прав доступа к данным, эффективная техника доступа к данным, а также многие другие. Период развития – 70-е годы. Концепция баз данных широко распространяется благодаря повышению характеристик аппаратного обеспечения компьютеров. Идет успешное внедрение систем, поддерживающих иерархическую и сетевую структуры данных. Период зрелости – 80-е годы. Реляционная модель получила полное теоретическое обоснование. Разработаны крупные реляционные СУБД Oracle, Informix, и другие. Промышленные реляционные системы получают широкое распространение во всех сферах человеческой деятельности. Реляционные системы практически вытеснили с мирового рынка ранние СУБД иерархического и сетевого типа. Дальнейшее развитие реляционных СУБД шло в следующих направлениях: Удобство применения. Появление персональных компьютеров сделал принципиальным вопрос удобства использования программ, что также относилось и к СУБД. На протяжении всего этого периода интенсивно развивается внешний интерфейс взаимодействия пользователей с базами данных. Многоплановость. Изначально базы данных разрабатывались для хранения и обработки символьной информации и традиционно использовались в таких сферах, как обработка экономической информации, статистика, банковское дело, системы резервирования, информационные системы различного направления. Появление спроса к базам данных в нетрадиционных сферах их применения, системы автоматизации проектирования, издательское дело и другие, потребовали хранения в базах данных и обработки изображений, звуков, полнотекстовой информации. Постреляционный период – с начало 90-х гг. В этот период начались проводиться интенсивные исследования по дедуктивным и объектно-ориентированным базам данных, а также разработка исследовательских прототипов таких систем. В связи с развитием Интернет-технологий прикладываются большие усилия по внедрению баз данных в Интернет. Возникают различные подходы по включению СУБД с их базами данных во всемирную паутину, начиная от простейших «публикаций» баз данных в Интернет и заканчивая разработкой web-серверов баз данных, которые в состоянии предоставлять весь спектр услуг пользователям Интернета по использованию баз данных на сервере. 32) Базовые понятия реляционных БД: тип данных, домен, атрибут, кортеж, отношение, схема отношений. Основными понятиями реляционных баз данных являются тип данных, домен, атрибут, кортеж, первичный ключ и отношение. Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации: 4.1.1. Тип данных Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал). Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres). В нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и "деньги". 4.1.2. Домен Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат "истина", то элемент данных является элементом домена. 4.1.3. Схема отношения, схема базы данных Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута). Схема БД (в структурном смысле) - это набор именованных схем отношений. 4.1.4. Кортеж, отношение Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа. Отношение - это множество кортежей, соответствующих одной схеме отношения. Иногда, чтобы не путаться, говорят "отношение-схема" и "отношение-экземпляр", иногда схему отношения называют заголовком отношения, а отношение как набор кортежей - телом отношения. На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования. Было бы вполне логично разрешать отдельно определять схему отношения, а затем одно или несколько отношений с данной схемой. 33) Проектирование баз данных. Создание информационной системы – это сложный процесс, в котором принимает участие коллектив разработчиков, разбивается на стадии проектирования, программной реализации и эксплуатации. В процессе создания информационной системы подготавливаются рабочие документы, служащие основой для всех разработчиков и пользователей системы. Проектирование базы данных заключается в многоступенчатом описании будущей БД с различной степенью детализации и формализации, в ходе которого производится уточнение и оптимизация ее структуры. Проектирование включает описание предметной области и задач информационной системы, далее идет к логическому описанию данных и затем – к физической модели БД. Различают три этапа детализации описания объектов БД и их взаимосвязей по трем основным уровням моделирования системы – концептуальному, логическому и физическому. На концептуальном уровне проектирования производится смысловое (семантическое) описание информационного содержания предметной области, определяются границы предметной области, производится абстрагирование от несущественных для данной информационной системы деталей. В результате определяются моделируемые объекты, их свойства и связи. Выполняется структуризация знаний о предметной области, стандартизируется терминология. Затем строится концептуальная модель, описываемая на естественном языке. Для описания свойств и связей объектов применяют различные диаграммы. На следующем шаге принимается решение о том, в какой СУБД будет реализована БД. Определяющими параметрами являются вид программного продукта и категория пользователей (профессиональные программисты или конечные пользователи, или и то, и другое). Другими показателями, влияющими на выбор СУБД, являются: удобство и простота использования; качество средств разработки, защиты и контроля БД; уровень коммуникационных средств (применение в сетях); фирма-разработчик; стоимость. Каждая конкретная СУБД работает с определенной моделью данных. На логическом уровне производится отображение данных концептуальной модели в логическую модель, поддерживаемую выбранной СУБД. Здесь объектом работы выступают сами данные, их структура и правила построения. Логическая модель не зависит от конкретной СУБД – построенная на основе таблиц логическая модель может быть реализована на любой СУБД реляционного типа. На физическом уровне производится выбор рациональной структуры хранения данных и методов доступа к ним, решаются вопросы эффективного выполнения запросов к БД, строятся дополнительные структуры, например, индексы. В физической модели содержится информация обо всех объектах БД (таблицах, индексах, процедурах и др.) и используемых типах данных. Физическая модель зависит от конкретной СУБД. Одной и той же логической модели может соответствовать несколько разных физических моделей. Физическое проектирование является начальным этапом реализации БД. 34) Архитектура Microsoft Access. Архитектура Microsoft Access Microsoft Access называет объектами все, что может иметь имя. В базе данных Access основными объектами являются таблицы, запросы, формы, отчеты, макросы и модули. В других СУБД, как правило, термин база данных обычно относится только к файлам, в которых хранятся данные. В Microsoft Access база данных включает в себя все объекты, связанные с хранимыми данными. Ниже приведен список основных объектов базы данных Access. 1. Таблица. Объект, который определяется и используется для хранения данных. Каждая таблица включает информацию об объекте определенного типа, например о клиентах. Таблица содержит поля (столбцы), в которых хранятся различного рода данные, например фамилия или адрес клиента, и записи (которые называются также строками). 2. Запрос. Объект, который позволяет пользователю получить нужные данные из одной или нескольких таблиц. Для создания запроса можно использовать бланк QBE (запрос по образцу) или инструкции SQL (структурированный язык запросов). Можно создать запросы на выборку, обновление, удаление или добавление данных. С помощью запросов можно также создавать новые таблицы, используя данные из одной или нескольких существующих таблиц. 3. Форма. Объект, предназначенный в основном для ввода данных, отображения их на экране или управления работой приложения. Формы можно также распечатать. 4. Отчет. Объект, предназначенный для создания документа, который впоследствии может быть распечатан или включен в документ другого приложения. 5. Макрос. Объект, представляющий собой структурированное описание одного или нескольких действий, которые должен выполнить Access в ответ на определенное событие. 6. Модуль. Объект, содержащий программы, написанные на языке Visual Basic для приложений. Событие – любое изменение состояния объекта Microsoft Access. Например, событием является открытие формы, закрытие формы, ввод новой строки в форму, изменение содержимого текущей записи или элемента управления (объекта формы или отчета, который может содержать данные). Для обработки события вы можете создать макрос или процедуру Visual Basic для приложений. 35) Назначение объектов MS Access Объектами базы данных Microsoft Access являются таблицы,запросы,формы,отчеты,макросы и модули.Каждый объект базы данных должен иметь имя, длина которого не должна превышать 64 символов, точка в имени объекта запрещена. Рассмотрим назначение каждого объекта базы данных: ТАБЛИЦА-служит для хранения информации,состоит из полей и записей.Между таблицами могут быть установлены связи.Они обеспечивают совместную обработку данных и целостность данных, благодоря им могут вноситься изменения сразу в несколько таблиц. ЗАПРОС-Это временная,результатирующая таблица,структурно она содержит те же элементы,что и базовая таблица.Назначение-извлечение данных из таблиц и других запросов и представление их пользователю в удобном виде. ФОРМА-окна программы,которые можно открыть из главного меню.Это средство отображения данных на экране и управлении ими. ОТЧЕТ-средство создания выходного документа для вывода на печать. МАКРОС-программа,содержащая описания последних действий,выполняемая при наступлении события в объекте. Основное назначение макросов — это создание удобного интерфейса приложения: чтобы формы и отчеты открывались при нажатии кнопок в форме или на панели инструментов или же привычным выбором команды меню. МОДУЛИ-процедуры на языке visual basic. 36) Построение таблиц в MS Access. В базе данных можно хранить данные в виде таблиц — тематических списков строк и столбцов. Например, вы можете создать таблицу "Контакты" для хранения имен, адресов и телефонных номеров или таблицу "Товары" для хранения сведений о товарах. В этой статье описано, как создать таблицу, добавить в нее поля, настроить первичный ключ и свойства таблицы и полей. Создание таблицы В простой базе данных, такой как список контактов, может быть всего одна таблица. Однако во многих базах данных используется несколько таблиц. При создании базы данных на компьютере создается файл, который используется как контейнер для всех ее объектов, включая таблицы. Есть несколько способов создать таблицу: вы можете создать новую базу данных, вставить таблицу в существующую базу данных или импортировать таблицу из другого источника данных, например книги Microsoft Office Excel, документа Microsoft Office Word, текстового файла или другой базы данных, либо связать таблицу с этим источником. Когда вы создаете новую базу данных, в нее автоматически вставляется новая пустая таблица. Затем вы можете ввести в нее данные, чтобы начать определение полей. К началу страницы Создание таблицы в новой базе данных Щелкните Файл > Создать и выберите пункт Пустая база данных рабочего стола. В поле Файл введите имя файла новой базы данных. Чтобы сохранить базу данных в другом месте, щелкните значок папки. Нажмите кнопку Создать. Откроется новая база данных, в которой будет создана и открыта в режиме таблицы новая таблица с именем "Таблица1". К началу страницы Создание таблицы в существующей базе данных Щелкните Файл > Открыть и выберите базу данных, если она указана в разделе Последние. В противном случае выберите один из вариантов поиска базы данных. В диалоговом окне Открытие файла базы данных найдите базу данных, которую вы хотите открыть,и нажмите кнопку Открыть. на вкладке Создание в группе Таблицы нажмите кнопку Таблица. В базу данных будет вставлена новая таблица, которая откроется в режиме таблицы. 37) Формы ввода-вывода данных в MS Access. Просмотр базы данных в виде таблицы в режиме заполнения дает пользователю возможность оценить базу как единое целое, сравнить записи и т.д. Часто, однако, возникает необходимость работы с отдельными записями базы. В этом случае присутствие на экране других записей (как это имеет место в режиме заполнения) только мешает и отвлекает. Работа с отдельными записями посредством форм позволяет сосредоточиться только на относящейся к делу информации. |