Базы данных, причины появления

Международный Славянский институт

Калининградский филиал 
 
 

Факультет Психология

Контрольная работа

По  дисциплине: Информатика  и ЭВМ в психологии

Тема(Вариант 16 ) Базы данных, причины  появления. 
 

                                                          Выполнила: студентка 3 курса

                        Группа:09П

                                                      Специальность: Психология

                               Бойченко Ю. А. 

                                               Научный руководитель:

                                                   К.пед.н., доцент Розен  Н.Б. 

г. Калининград

2012 г. 

Содержание 

Введение…………………………………………………………………………..3

1.Интегрированная база данных - констатация идеи…………………………5

1.1.За идеей - классическая методология проектирования…………………..6

1.2.За методологией - мастерская инструментов проектирования БД……..8

1.3.Особо - о временных характеристиках и транзакциях…………………..9

2.Оценка достигнутого состояния…………………………………………….11

2.1.Что и как из классических методов проектирования применяется в практике настоящего времени…………………………………………………..12

2.2.Что теряется в базах данных………………………………………………..13

3.Ограничения классических методов…………………………………………15

3.1.Причины появления новых требований…………………………………..16

3.2.Что нужно от баз данных для ответа на новые требования…………….17

3.3.Вошедшие в практику новые инструменты мастерской проектировщика

…………………………………………………………………………………….19

4.Понятийные модели и последующие проектные работы…………………27

Заключение………………………………………………………………………30

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

Введение 

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

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

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

       Исторически сложилось так, что до середины 90-х годов были наиболее развиты решения по автоматизации оперативной деятельности (учет людских, материальных и финансовых ресурсов, регистрация различных операций и событий) - системы транзакционной обработки данных (OLTP – On-Line Transaction Processing), часто называемые оперативными системами. Эти системы обеспечивают регистрацию некоторых фактов, их непродолжительное хранение и сохранение в архивах, обеспечивают решение лишь оперативных, в меньшей мере тактических, но не обеспечивают решение стратегических задач, а потому не удовлетворяет в полной мере потребности бизнеса.

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

1. Интегрированная база данных - констатация идеи

 

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

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

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

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

1.1.За идеей - классическая методология проектирования

       Классическая методология проектирования БД - это мощное и красивое течение со своей философией, способами восприятия реальности и способами существования в ней. В этом течении возникла своя прикладная математика, свое понятие "Мира", "Предметной Области" (ПрО) и их моделей. В отношении проектирования БД осознаны и интегрированы в стройные схемы методы выполнения таких проектных этапов:

- сбор сведений о ПрО (анализ потребностей и описание ПрО с использованием так называемых "процессного" или UP, "usage perspective" подхода и "непроцессного" или ISP, "information structure perspective" подхода);

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

- анализ собранных сведений о ПрО: классификация, формализация и интеграция структурных элементов описания ПрО, формализация как структурных, так и процедурных ограничений целостности элементов в будущей модели ПрО, определение динамики экземпляров объектов ПрО;

- синтез концептуальной модели БД: проектирование целостной концептуальной схемы БД на выбранном языке семантического моделирования;

-  выбор конкретной модели данных и СУБД для реализации БД;

- проектирование логической схемы БД для выбранной СУБД (называющееся также "проектирование реализации");

- разработка физической структуры БД ("физической" или "внутренней" схемы, она же - "схема размещения"), включая размещение БД по узлам;

-  разработка технологии и процедур начального создания и заполнения БД;

-  разработка технологии и процедур сопровождения БД;

- разработка универсальных программ доступа к БД и соответствующих интерфейсов пользователей;

- информационное обеспечение разработки конкретных программ обработки данных: обеспечение метаинформацией, данными контрольных примеров и др.;

- получение обратной связи от разработчиков прикладных программ и пользователей Информационной Системы (ИС) о полноте и эффективности организации БД;

- тестирование БД, ее развитие и улучшение (настройка) ее структуры.

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

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

 

1.2.За методологией - мастерская инструментов проектирования БД

       Проектирование комплексной по предметной направленности, интегрированной и, обычно, большой по размеру БД стало сложной задачей. Наличие целостной методологии проектирования позволило позаботиться о "сапожнике-проектировщике" и начать шить ему сапоги в виде систем автоматизации проектирования БД. Этому способствовало наличие технологического опыта в организации и компьютерной поддержке систем разработки программного обеспечения и, с другой стороны, использование активных интегрированных словарей-справочников данных (DD/D, Data Dictionary/Directory). Так возникли системы CASE (Computer Aided System Engineering) - системы для структурного проектирования БД и связанных с ними ИС, ориентированные на модели данных, реализованные в различных СУБД. Наибольшую популярность получили CASE-системы для реляционных СУБД с SQL-моделями данных, а DD/D переименовался в CASE-репозиторий проектируемой ИС.

       На этом пути возникло два основных направления развития CASE-систем и технологий проектирования: CASE-системы для проектирования собственно БД (или т. н. Upper-CASE) и интегрированные инструменты, позволяющие и проектировать БД, и разрабатывать использующие их прикладные программы. Важно отметить, что и Upper-CASE в общем случае имеют много средств для описания функций обработки информации (при использовании процессного подхода к сбору и анализу сведений о ПрО) и хранения этих описаний в репозитории. Это подтверждает положение о сильной связи проекта БД и проекта ИС, базирующейся на этой БД. Вместе с тем, эта связь не абсолютна, и принцип отделения БД от программ сохраняется.

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

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