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

Эпилог

При подготовке данной статьи я постаралась ориентироваться прежде всего на архитекторов, аналитиков и разработчиков, которые непосредственно работают с хранилищами данных. Но получилось, что неизбежно «брала тему чуть шире» - и поле зрения попадали другие категории читателей. Какие-то моменты покажутся спорны, какие-то не понятны, какие-то очевидны. Люди разные – с разным опытом, бэкграундом и позицией.
Например, типичные вопросы менеджеров - «когда привлекать архитекторов?», «когда надо заниматься архитектурой?», «архитектура – не будет ли это слишком дорого?» звучат для нас (разработчиков, проектировщиков) довольно странно, потому что для нас архитектура системы появляется с ее рождением – не важно, осознаем мы это, или нет. И даже если формально роли архитектора в проекте нет, нормальный разработчик всегда «включает своего внутреннего архитектора».

По большом счету, не важно – кто именно выполняет роль архитектора – важно, что кто-то ставит подобные вопросы и исследует на них ответы. Если архитектор явно выделен – это лишь означает, что ответственность за систему и ее развитие несет, прежде всего, он.
Почему мне показалась тема «антихрупкости» релевантной относительно данного предмета?

“Уникальность антихрупкости состоит в том, что она позволяет нам работать с неизвестностью, делать что-то в условиях, когда мы не понимаем, что именно делаем, – и добиваться успеха” /Нассим Н.Талеб/

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

Теги: Добавить метки

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

Эпилог

При подготовке данной статьи я постаралась ориентироваться прежде всего на архитекторов, аналитиков и разработчиков, которые непосредственно работают с хранилищами данных. Но получилось, что неизбежно «брала тему чуть шире» - и поле зрения попадали другие категории читателей. Какие-то моменты покажутся спорны, какие-то не понятны, какие-то очевидны. Люди разные – с разным опытом, бэкграундом и позицией.
Например, типичные вопросы менеджеров - «когда привлекать архитекторов?», «когда надо заниматься архитектурой?», «архитектура – не будет ли это слишком дорого?» звучат для нас (разработчиков, проектировщиков) довольно странно, потому что для нас архитектура системы появляется с ее рождением – не важно, осознаем мы это, или нет. И даже если формально роли архитектора в проекте нет, нормальный разработчик всегда «включает своего внутреннего архитектора».

По большом счету, не важно – кто именно выполняет роль архитектора – важно, что кто-то ставит подобные вопросы и исследует на них ответы. Если архитектор явно выделен – это лишь означает, что ответственность за систему и ее развитие несет, прежде всего, он.
Почему мне показалась тема «антихрупкости» релевантной относительно данного предмета?

“Уникальность антихрупкости состоит в том, что она позволяет нам работать с неизвестностью, делать что-то в условиях, когда мы не понимаем, что именно делаем, – и добиваться успеха” /Нассим Н.Талеб/

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

Теги:

• архитектура
• хранилище данных

Добавить метки

Отраслевые модели данных

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

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

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

Как правило, выделяются модели более высокого уровня (и более общие по содержанию) и более низкого (соответственно, более детальные). Верхний уровень моделирования – это так называемые концептуальные модели данных (conceptual data models), которые дают самую общую картину функционирования предприятия или организации. Концептуальная модель включает основные концепции или предметные области, критичные для функционирования организации; обычно их количество не превышает 12-15. Такая модель описывает классы сущностей, важных для организации (бизнес-объекты), их характеристики (атрибуты) и ассоциации между парами этих классов (т.е. связи). Поскольку в бизнес-моделировании терминология еще окончательно не устоялась, в различных англоязычных источниках концептуальные модели данных могут также носить название subject area model (что можно перевести как модели предметных областей) или subject enterprise data model (предметные корпоративные модели данных).

Следующий иерархический уровень – это логические модели данных (logical data models). Они также могут называться корпоративными моделями данных или бизнес-моделями. Эти модели содержат структуры данных, их атрибуты и бизнес-правила и представляют информацию, используемую предприятием, с точки зрения бизнес-перспективы. В такой модели данные организованы в виде сущностей и связей между ними. Логическая модель представляет данные таким образом, что они легко воспринимаются бизнес-пользователями. В логической модели может быть выделен словарь данных – перечень всех сущностей с их точными определениями, что позволяет различным категориям пользователей иметь общее понимание всех входных и информационных выходных потоков модели. Следующий, более низкий уровень моделирования – это уже физическая реализация логической модели с помощью конкретных программных средств и технических платформ.

Логическая модель содержит детальное корпоративное бизнес-решение, которое обычно принимает форму нормализованной модели. Нормализация – это процесс, который гарантирует, что каждый элемент данных в модели имеет только одно значение и полностью и однозначно зависит от первичного ключа. Элементы данных организуются в группы согласно их уникальной идентификации. Бизнес-правила, управляющие элементами данных, должны быть полностью включены в нормализованную модель с предварительной проверкой их достоверности и корректности. Например, такой элемент данных, как Имя клиента, скорее всего, будет разделен на Имя и Фамилию и сгруппирован с другими соответствующими элементами данных в сущность Клиент с первичным ключом Идентификатор клиента.

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

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

У компании может быть два пути создания корпоративной логической модели данных: строить ее самостоятельно или воспользоваться готовой отраслевой моделью (industry logical data model). В данном случае различия в терминах отражают лишь разные подходы к построению одной и той же логической модели. В том случае, если компания самостоятельно разрабатывает и внедряет собственную логическую модель данных, то такая модель, как правило, носит название просто корпоративной логической модели. Если же организация решает воспользоваться готовым продуктом профессионального поставщика, то тогда можно говорить об отраслевой логической модели данных. Последняя представляет собой готовую логическую модель данных, с высокой степенью точности отражающую функционирование определенной отрасли. Отраслевая логическая модель – это предметно-ориентированный и интегрированный вид всей информации, которая должна находиться в корпоративном Хранилище данных для получения ответов как на стратегические, так и на тактические бизнес-вопросы. Как и любая другая логическая модель данных, отраслевая модель не зависит от прикладных решений. Она также не включает производные данные или другие вычисления для более быстрого извлечения данных. Как правило, большинство логических структур такой модели находят хорошее воплощение в ее эффективной физической реализации. Такие модели разрабатываются многими поставщиками для самых различных областей деятельности: финансовой сферы, производства, туризма, здравоохранения, страхования и т.д.

Отраслевая логическая модель данных содержит информацию, общую для отрасли, и поэтому не может быть исчерпывающим решением для компании. Большинству компаний приходится увеличивать модель в среднем на 25% за счет добавления элементов данных и расширения определений. Готовые модели содержат только ключевые элементы данных, а остальные элементы должны быть добавлены к соответствующим бизнес-объектам в процессе установки модели в компании.

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

Специалист в области бизнес-аналитики (Business Intelligence) Стив Хобермэн (Steve Hoberman) выделяет пять факторов, которые необходимо принимать во внимание при решении вопроса о приобретении отраслевой модель данных. Первый – это время и средства, необходимые для построения модели. Если организации необходимо быстро добиться результатов, то отраслевая модель даст преимущество. Использование отраслевой модели не может немедленно обеспечить картину всей организации, но способно сэкономить значительное количество времени. Вместо собственно моделирования время будет потрачено на связывание существующих структур с отраслевой моделью, а также на обсуждение того, как лучше ее настроить под нужды организации (например, какие определения должны быть изменены, а какие элементы данных – добавлены).

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

Третий фактор – опыт в оценке рисков и моделировании. Создание корпоративной модели данных требует квалифицированных ресурсов как со стороны бизнеса, так и IT-персонала. Как правило, менеджеры хорошо знают либо работу организации в целом, либо деятельность конкретного отдела. Лишь немногие их них обладают как широкими (в масштабах всей компании), так и глубокими (в рамках подразделений) знаниями о своем бизнесе. Большинство менеджеров обычно хорошо знают только одну область. Поэтому, для того чтобы получить общекорпоративную картину, требуются существенные бизнес-ресурсы. Это увеличивает и требования к IT-персоналу. Чем больше бизнес-ресурсов требуется для создания и тестирования модели, тем более опытными должны быть аналитики. Они должны не только знать, как получить информацию от бизнес-персонала, но также уметь находить общую точку зрения в спорных областях и быть способными представлять всю эту информацию в интегрированном виде. Тот, кто занимается созданием модели (во многих случаях это тот же аналитик), должен обладать хорошими навыками моделирования. Создание корпоративных логических моделей требует моделирования «для будущего» и способности конвертировать сложный бизнес в буквальном смысле «в квадраты и линии».

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

Четвертый фактор – существующая инфраструктура приложений и связи с поставщиками. Если организация уже использует много инструментов одного и того же поставщика и имеет налаженные связи с ним, то имеет смысл и отраслевую модель заказывать у него же. Такая модель сможет свободно работать с другими продуктами этого же поставщика.

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

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

Отраслевые модели данных обеспечивают компаниям единое интегрированное представление их бизнес-информации. Многим компаниям бывает непросто осуществить интеграцию своих данных, хотя это является необходимым условием для большинства общекорпоративных проектов. По данным исследования Института Хранилищ данных (The Data Warehousing Institute, TDWI), более 69% опрошенных организаций обнаружили, что интеграция является существенным барьером при внедрении новых приложений. Напротив, осуществление интеграции данных приносит компании ощутимый доход.

Отраслевая модель данных, помимо связей с уже существующими системами, дает большие преимущества при осуществлении общекорпоративных проектов, таких как планирование ресурсов предприятия (Enterprise Resource Planning, ERP), управление основными данными, бизнес-аналитика, повышение качества данных и повышение квалификации сотрудников.

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

Публикации

1. Стив Хобермэн (Steve Hoberman). Использование отраслевой логической модели данных в качестве корпоративной модели (Leveraging the Industry Logical Data Model as Your Enterprise Data Model).
2. Клодиа Имхоф (Claudia Imhoff). Оперативное создание Хранилищ данных и выполнение проектов Business Intelligence с помощью моделирования данных (Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling)

Цель лекции

Изучив материал настоящей лекции, вы будете знать:

• что такое корпоративная модель данных ;
• как преобразовать корпоративную модель данных в модель хранилища данных;
• основные элементы корпоративной модели данных ;
• уровни представления корпоративной модели данных ;
• алгоритм преобразования корпоративной модели данных в многомерную модель хранилища данных ;

и научитесь:

• разрабатывать модели хранилища данных на основе корпоративной модели данных организации;
• разрабатывать схему "звезда" с помощью CASE-средств;
• секционировать таблицы многомерной модели с помощью CASE-средств.

Корпоративная модель данных

Введение

Ядром любого ХД является его модель данных. Без модели данных будет очень сложно организовать данные в ХД. Поэтому разработчики ХД должны потратить время и силы на разработку такой модели. Разработка модели ХД ложится на плечи проектировщика ХД.

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

Отправной точкой в проектировании ХД может служить так называемая корпоративная модель данных ( corporate data model или enterprise data model, EDM ), которая создается в процессе проектирования OLTP-систем организации. При проектировании корпоративной модели данных обычно предпринимается попытка создать на основе бизнес-операций такую структуру данных, которая бы собрала и синтезировала в себе все информационные потребности организации.

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

Корпоративная модель данных

Как решить задачу преобразования корпоративной модели данных в модель ХД? Чтобы решить эту задачу, нужно иметь эту модель, т.е. корпоративная модели данных должна быть построена и документирована . И нужно понять, что из этой модели и как должно трансформироваться в модель ХД.

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

Основными элементами корпоративной модели данных являются:

• описание предметных областей организации (определение сфер деятельности);
• взаимоотношения между определенными выше предметными областями;
• информационная модель данных ( ERD -модель или модель "сущность-связь");
• для каждой предметной области описание:
  • ключей сущностей;
  • атрибутов сущностей ;
  • подтипов и супертипов ;
  • связей между сущностями;
  • группировки атрибутов;
  • взаимосвязей между предметными областями;
• функциональная модель или модель бизнес-процессов;
• диаграммы потоков данных;
• диаграммы состояний;
• другие модели.

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

Уровни представления корпоративной модели данных

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

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

Корпоративная модель данных обычно имеет несколько уровней представления. На самом высоком уровне (high level) корпоративной модели данных располагается описание основных предметных областей организации и их взаимосвязей на уровне сущностей. На рис. 16.2 приведен фрагмент корпоративной модели данных верхнего уровня.

Рис. 16.2.

На схеме, приведенной на рисунке, представлено четыре предметных области: "Покупатель" (Customer ), "Счет" (account ), "Заказ" (Order ) и "Товар" (Product ). Как правило, на верхнем уровне представления модели указываются только прямые связи между предметными областями, которые, например, фиксируют следующий факт: покупатель оплачивает счет на заказ товаров. Подробная информация и косвенные взаимосвязи на этом уровне корпоративной модели не приводятся.

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

Из рис. 16.3 видно, что предметная область "Заказ" (Order ) включает в себя несколько сущностей, определенных через их атрибуты, и взаимосвязей между ними. Представленная модель позволяет ответить на такие вопросы, как дата заказа, кто сделал заказ, кто отправил заказ, кто получает заказ и ряд других. Из приведенной схемы видно, что в данной организации выделяют два типа заказов – заказы по рекламной акции (Commersial ) и заказы по розничной торговле (Retail ).

Заметим, что корпоративная модель данных может представлять различные аспекты деятельности организации и с различной степенью детализации и завершенности. Если корпоративная модель представляет все аспекты деятельности организации, она еще называется моделью данных организации ( enterprise data model).

С точки зрения проектирования ХД важным фактором в принятии решения создания модели ХД из корпоративной модели данных является состояние завершенности корпоративной модели данных .

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

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

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

• 1. Реляционная модель данных
• 1.1 Реляционная модель данных. Основные определения
• 1.2 Операции над отношениями
• 2. Корпоративные информационные системы
• Список используемой литературы

1. Реляционная модель данных

1.1 Реляционная модель данных. Основные определения

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

Основные понятия:

* Отношение представляет собой двумерную таблицу, содержащую некоторые данные.

* Сущность - объект любой природы, данные о котором хранятся в БД. Атрибуты - свойства, характеризующие сущность (столбцы).

* Степень отношения - количество столбцов.

* Схема отношения - список имен атрибутов, например, СОТРУДНИК (№, ФИО, Год рождения, Должность, Кафедра).

* Домен - совокупность значений атрибутов отношения (тип данных).

* Кортеж - строка таблицы.

* Кардинальность (мощность) - количество строк в таблице.

* Первичный ключ - это атрибут, уникально идентифицирующий строки отношения. Первичный ключ из нескольких атрибутов называется составным. Первичный ключ не может быть полностью или частично пустым (иметь значение null). Ключи, которые можно использовать в качестве первичных, называются потенциальными или альтернативными ключами.

* Внешний ключ - это атрибут (атрибуты) одной таблицы, который может служить первичным ключом другой таблицы. Является ссылкой на первичный ключ другой таблицы.

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

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

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

1.2 Операции над отношениями

Чтобы привести таблицу к первой нормальной форме (1НФ), нужно соблюсти два правила:

1. Атомарность или неделимость. Каждая колонка должна содержать одно неделимое значение.

2. Таблица не должна содержать повторяющихся колонок или групп данных.

Например, если таблица содержит в одном поле полный адрес человека (улица, город, почтовый код), не будет отвечать правилам 1НФ, поскольку будет содержать различные значения в одном столбце, что будет нарушением правила об атомарности. Или если бд содержит данные о фильмах и в ней есть столбцы актер1, актер2, актер3, также не будет отвечать правилам, поскольку будет иметь место повторению данных.

Начинать нормализацию следует с проверки структуры БД на совместимость с 1НФ. Все столбцы, которые не являются атомарными, должны быть разбиты на составляющие их столбцы. Если в таблице есть повторяющиеся столбцы, то им нужно выделить отдельную таблицу.

Чтобы привести таблицу к первой нормальной форме, следует:

* Найти все поля, которые содержат многосоставные части информации.

* Те данные, которые можно разбить на составные части, нужно выносить в отдельные поля.

* Вынести повторяющиеся данные в отдельную таблицу.

* Проверить, все ли таблицы подходят под условия первой нормальной формы.

Для приведения таблиц ко второй нормальной форме (2НФ), приводимые таблицы должны быть уже в 1НФ. Нормализация должна проходить по порядку.

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

Чтобы привести базу ко второй нормальной форме, надо:

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

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

* Для каждой таблицы нужен свой первичный ключ

* Создать внешние ключи и обозначаем их отношения между таблицами. Конечным шагом нормализации до 2НФ будет являться выделение внешних ключей для связи с ассоциированными таблицами. Первичный ключ одной таблицы должен быть внешним ключом в другой.

Подсказки:

Другой способ приведения схемы к 2НФ -- посмотреть на отношения между таблицами. Идеальный вариант -- создать все отношения вида один-к-многим. Отношения вида многие-к-многим нуждаются в реструктуризации.

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

База данных будет находиться в третьей нормальной форме, если она приведена ко второй нормальной форме и каждый не ключевой столбец независим друг от друга. Если следовать процессу нормализации правильно до этой точки, с приведением к 3НФ может и не возникнуть вопросов. Следует знать, что 3НФ нарушается, если изменив значение в одном столбце, потребуется изменение и в другом столбце.

Чтобы привести базу к третьей нормальной форме, надо:

* Определить, в каких полях каких таблиц имеется взаимозависимость, т.е. поля, которые зависят больше друг от друга, чем от ряда в целом.

* Создать соответствующие таблицы. Если есть проблемный столбец в шаге 1, создать раздельные таблицы для него.

* Создать или выделить первичные ключи. Каждая таблица должна иметь первичный ключ.

* Создать необходимые внешние ключи, которые образуют любое из отношений.

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

2. Корпоративные информационные системы

реляционный модель данные система

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

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

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

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

4. Архитектура системы -- совокупность свойств системы, существенных для пользователя.

5. Целостность системы -- принципиальная несводимость свойств системы к сумме свойств отдельных ее элементов (эмерджентность свойств) и, в то же время, зависимость свойств каждого элемента от его места и функции внутри системы.

Информационная система -- взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели»

В Федеральном законе «Об информации, информатизации и защите информации» дается следующее определение:

«Информационная система -- организационно упорядоченная совокупность документов (массивов документов) и информационных технологий, в том числе с использованием средств вычислительной техники и связи, реализующих информационные процессы»

Классификация по масштабу

По масштабу информационные системы подразделяются на следующие группы:

* одиночные;

* групповые;

* корпоративные.

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

Корпоративной Информационной Системой может считаться система, автоматизирующая более 80 % подразделений предприятия.

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

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

Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Microsoft SQL Server.

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

Классификация по сфере применения

По сфере применения информационные системы обычно подразделяются на четыре группы:

* системы обработки транзакций;

* системы принятия решений;

* информационно-справочные системы;

* офисные информационные системы.

Список используемой литературы

1. Агальцов, В.П. Базы данных. В 2-х т. Т. 2. Распределенные и удаленные базы данных: Учебник / В.П. Агальцов. - М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013.

2. Голицына, О.Л. Базы данных: Учебное пособие / О.Л. Голицына, Н.В. Максимов, И.И. Попов. - М.: Форум, 2012.

3. Карпова, И.П. Базы данных: Учебное пособие / И.П. Карпова. - СПб.: Питер, 2013.

4. Кириллов, В.В. Введение в реляционные базы данных.Введение в реляционные базы данных / В.В. Кириллов, Г.Ю. Громов. - СПб.: БХВ-Петербург, 2012.

5. Пирогов, В.Ю. Информационные системы и базы данных: организация и проектирование: Учебное пособие / В.Ю. Пирогов. - СПб.: БХВ-Петербург, 2009.

6. Г.Н. Федорова. Информационные системы. - М.: Академия, 2013.

7. А.Е. Сатунина, Л.А. Сысоева. Управление проектом корпоративной информационной системы предприятия. - М.: Финансы и статистика, Инфра-М, 2009.

Размещено на Allbest.ru

...

Подобные документы

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

курсовая работа , добавлен 29.01.2011


Корпоративные информационные системы и базы данных, их использование для совершенствования и отлаживания ведения бизнеса. Классификация корпоративных информационных систем. Информационные системы класса OLTP. Оперативная аналитическая обработка.

курсовая работа , добавлен 19.01.2011


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

реферат , добавлен 20.12.2010


Понятие системы базы данных. Реляционная модель и ее характеристики. Целостность в реляционной модели. Реляционная алгебра. Вопросы проектирования БД. Нормальные формы отношений. Проектирование БД методом сущность-связь. ER-диаграммы. Язык SQL.

курс лекций , добавлен 03.10.2008


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

презентация , добавлен 14.10.2013


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

реферат , добавлен 19.12.2011


Виды и функции системы управления базами данных Microsoft Access. Иерархическая, сетевая, реляционная модель описания баз данных. Основные понятия таблицы базы данных. Особенности создания объектов базы данных, основные формы. Доступ к Internet в Access.

контрольная работа , добавлен 08.01.2011


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

научная работа , добавлен 08.06.2010


Модели данных в управлении базами данных. Концептуальные модели данных. Роль баз данных в информационных системах. Реляционная модель данных. Определение предметной области. Построение модели базы данных для информационной системы "Домашние животные".

курсовая работа , добавлен 19.04.2011


Информационная модель в Access как некоторый упрощенный заменитель реального объекта или системы. Основные структуры, определяющие организацию данных и связей между ними; реляционная разновидность организации данных. Пример базы данных в налогообложении.