개념 설계의 단계입니다. 데이터 베이스. 물리적 세계의 객관적 법칙

지식 기반에서 좋은 작업을 보내는 것은 간단합니다. 아래 양식을 사용하세요

잘 했어사이트로">

연구와 작업에 지식 기반을 사용하는 학생, 대학원생, 젊은 과학자들은 매우 감사할 것입니다.

http://www.allbest.ru/에서 호스팅

러시아 연방 교육 과학부

연방 주 예산 교육 기관

고등 전문 교육

볼고그라드 주립 기술 대학

공학 인력 양성 학부

부서 "컴퓨터 지원 디자인 및 검색

건설"

코스 작업

코스 "개념 시스템 설계"

완료자: AUZ-361s Tyulyaeva I.A. 그룹의 학생

확인됨: 성. pr. Orlova T.A.

볼고그라드 2013

소개

1) 시스템의 구조 및 기능 분석 수행

1. 원래 시스템에 대한 설명

연구 대상

구두 설명

연구 제한

시스템 정의의 목적

시스템 분류

시스템의 구조 및 기능 분석

그래픽 형태의 구조 및 기능적 구조

2) 기술적 개체의 기능 및 물리적 분석 수행

1. 기술적 개체의 기능 및 물리적 분석

2. 흐름 기능적 구조

3) 기술적 대상의 형태학적 분석 및 형태적 합성 수행

1. 기술적 목적에 대한 설명

2. 기술적 객체의 형태학적 분석

2.1 형태학적 분석의 목적

형태표

가능한 기술 솔루션의 총 수

가능한 기술 솔루션의 최종 총 수

3. 기술적 객체의 형태적 합성

3.1 형태학적 합성의 목적

전문가 평가 표

하나의 기준에 의한 합성

모든 기준에 의한 합성

결론

사용된 소스 목록

소개

창조 현대적인 디자인매우 효과적인 기술은 발명의 수준에서 새롭고 비할 데 없는 독창적이며 경우에 따라 선구적인 기술 솔루션을 찾아야 할 필요성과 관련이 있습니다. 그들은 다양한 목적을 위한 복잡한 기술과 기술 시스템의 개발을 제공합니다.

이 작업의 목적은 기술 시스템 및 기술의 생성에 사용되는 방법의 기본 아이디어와 원리를 익히는 것입니다.

이 작업의 결과로 학생은 다음을 배우고 배워야 합니다.

기술적 개체 설계에서 해결된 작업의 주요 기능

기술적 개체 설계에서 솔루션의 분석 및 합성에 과학적 접근 방식을 적용합니다.

기술 개체 설계를 위한 자동화 시스템 구축을 위한 기술 솔루션의 분석 및 합성 방법을 사용합니다.

개념 설계 지원을 위한 자동화 시스템 생성 문제를 설정하고 해결합니다.

1) 시스템의 구조 및 기능 분석 수행

목적 :

1. 원래 시스템에 대한 설명

1.1 연구 대상

연구의 대상은 충격식 전기 커피 그라인더입니다. 전자 조절기가 없는 전기 커피 분쇄 시스템으로 대상을 정의해 보겠습니다.

1.2 구두 설명

전기 커피 그라인더의 자동화 시스템은 분쇄의 균일성과 강도를 보장하도록 설계되었습니다. 임팩트 전동 커피 그라인더 시스템의 특징은 고속으로 회전하는 칼을 사용하여 볶은 커피 원두를 분쇄하는 것입니다.

시스템에서 커피 원두(V2)의 발신자(V1)는 커피 원두 호퍼에 커피 원두를 공급하고 분쇄 ​​커피 호퍼에서 생성된 분쇄 커피 분말을 내리는 책임도 있는 사람입니다.

"시작" 버튼을 누르면 전기 커피 그라인더가 켜지고 꺼집니다. 이러한 시스템을 사용하면 언제든지 연삭 공정을 중단할 수 있습니다. 고주파전기 모터의 회전으로 몇 초 만에 칼로 곡물을 갈 수 있습니다. 연삭 시간에 따라 미세, 중, 대 중 원하는 정도의 연삭을 얻을 수 있습니다. 칼은 커피 그라인더에 직접 설치되어 있어 전동 커피 그라인더에는 뚜껑을 열면 모터가 꺼지는 잠금 장치가 장착되어 있습니다. 프레스 분쇄 커피는 착탈식 호퍼로 배출됩니다.

1.3 연구 제한

이 시스템을 연구할 때 연구 대상에 대한 외부 환경의 영향은 고려되지 않습니다. 연구 중인 시스템에 직접적인 영향을 미치는 외부 환경으로 사람과 커피 원두를 고려한다. 이 시스템은 분쇄 커피 원두의 균일성과 강도를 보장하도록 설계되었으며, 그 크기는 시스템 작동을 방해하지 않아야 합니다.

1.4 시스템 정의의 목적

수작업 및 추가 장비 및 기술을 사용하지 않고 커피 원두를 분쇄하는 방법의 조사 및 이 시스템의 효과적인 획득 개발.

2. 시스템 분류

연구 중인 시스템은 복잡한 기술적 결정론적 시스템에 속합니다.

시스템은 개방형 시스템, 환경과 상호 작용하고 살아 있지 않기 때문입니다.

시스템은 객체인 요소가 2개 이상 있기 때문에 구체적입니다.

자동 전기 커피 그라인더는 사람이 만든 인공 물리적 시스템에 속합니다.

객체 시스템에 대한 설명은 추상적으로 설명되기 때문에 수학적 데이터 처리에 사용할 수 없습니다. 즉, 속성은 변수로, 기본 속성은 매개변수로 설명됩니다.

각 블록은 변수의 하나의 상태를 나타냅니다. 관찰 가능한 속성이 매개변수의 특정 값으로 유지되면 관찰된 속성은 속성의 표현 집합에서 특정 표현을 받습니다.

다른 속성이 관찰되는 속성을 기본 속성이라고 합니다. 임팩트형 전동 커피 그라인더 시스템의 기본 속성은 원두 분쇄량이라고 할 수 있습니다.

3. 구조적으로 -시스템의 기능적 분석

표 1. 구조적 및 기능적 구조

시스템 요소

요소 기능

이름

구두 설명

E 4를 열 때 영향을 미치고

닫히면 작동을 멈춘다

V 2를 갈고 E 3에서 작업 결과를 통과합니다.

원두커피용 호퍼

V 1은 V 2를 요소 E 2에 넣고 E 1을 시작합니다.

V 2를 E 7로 밉니다.

차단 장치

Е 0을 열고 닫는 사실을 수정하고 Е 5를 차단/차단 해제합니다.

전기 모터

E 6에서 신호를 받은 다음 E 1을 시작하라는 신호를 보냅니다.

스위치

E 5에 영향을 미치고 V 1을 다시 누르면 멈춥니다.

원두커피용 호퍼

매장 그라운드 V 2

4. 그래픽 표현

쌀. 1. 그래픽 형태의 구조적 및 기능적 구조.

2) 기술적 개체의 기능적 및 물리적 분석 수행

목적: 자동화 시스템의 기능-물리적 분석을 연구하고 설계에서 이 방법으로 작업하는 기술 습득 자동화 시스템.

1. 기술적 개체의 기능 및 물리적 분석

외부 환경: V 1 - 사람, V 2 - 커피 콩.

표 #2: 기능적-물리적 구조

시스템 요소

물리적 조작

이름

입력 작업

콜러 작전

출력 동작 B

물리적 인

V 1의 영향

변환

E 4에 신호

V 2에 미치는 영향

변환

E 3에 신호

원두커피용 호퍼

물리적 인

V 1에서 V 2로의 영향

변환

E 1에 신호

E 1의 신호

움직이는

전송 V 2 ~ E 7

차단 장치

위치 E 0

변환

E 5에 신호

전기 모터

E 4 및 E 6의 신호

변환

E 1에 신호

스위치

물리적 인

V 1의 영향

변환

E 5에 신호

원두커피용 호퍼

지연 V 2

움직이는

스토리지 V2

처리를 위한 후속 전송

2. 감자 기능적 구조

쌀. 2. 그래픽 형태의 흐름 기능적 구조.

3) 형태학적 분석 및 형태학적 합성 수행기술적 개체

목적: 자동화 시스템의 구성적 기능 분석을 연구하고 자동화 시스템을 설계할 때 이 방법으로 작업하는 기술을 습득합니다.

1. 기술적 목적에 대한 설명

이 시스템은 커피 원두를 분쇄하는 균일성과 강도를 보장하도록 설계된 자동화된 전기 커피 그라인더 시스템입니다. 임팩트 전동 커피 그라인더 시스템의 특징은 고속으로 회전하는 칼을 사용하여 볶은 커피 원두를 분쇄하는 것입니다. 본 발명은 다양한 종류의 전기 신호를 처리하고 스위칭을 수행하는 장치로서의 전기 공학에 관한 것입니다.

전기(new-lat. electricus 및 기타 그리스어 lekfspn에서) - 전기, 반짝이는 금속; 호박색.

2. 기술적 객체의 형태학적 분석

2.1 형태학적 분석의 목적

분석의 목적은 미래에 합성 절차를 사용하여 보다 안정적이고 비용 효율적인 새로운 기술 솔루션을 만들 수 있는 기반이 되는 형태학적 매트릭스를 만드는 것입니다.

고려 중인 시스템을 개선해야 합니다.

요구 사항: 시스템의 신뢰성과 기능을 높이는 것이 필요합니다.

목적: 고정 정확도와 성능을 향상시킵니다.

2.2 형태표

건설적인 형태학적 자동화 전기 커피 그라인더

표 3: 기술적 개체의 형태학적 표.

분류 기능

분류 기능에 대한 구현 옵션

V 1 1 - 강철;

V 1 2 - 알루미늄; V 1 3 - 플라스틱;

V 2 1 - 강철;

V 2 2 - 알루미늄; V 2 3 - 황동;

원두커피용 호퍼

V 3 1 - 강철;

V 3 2 - 플라스틱;

V 4 1 - 피스톤;

V 4 2 - 유압;

차단 장치

V 5 1 - 버튼;

V 5 2 - 접촉판;

V 5 3 - 광전지;

스위치

V 6 1 - 자동;

V 6 2 - 버튼;

원두커피용 호퍼

V 7 1 - 강철;

V 7 2 - 플라스틱;

2.3 총 수량

가능한 기술 솔루션의 총 수:

3 * 3 * 2 * 2 * 3 * 2 * 2 = 432

가능한 조합의 수를 줄이기 위해 다음과 같이 덜 중요한 분류 기능을 버릴 수 있습니다.

원두커피용 호퍼.

원두커피용 호퍼.

스위치.

또한 나머지 분류 기능 각각에서 가장 유용하지 않은 것을 버리고 대안의 수를 줄입니다.

2.4 최종 총 수량가능한 기술 솔루션에 대해

표 #4: 최종 테이블.

가능한 기술 솔루션의 최종 총 수:

3 * 3 * 2 * 2 = 36

3. 기술적 객체의 형태적 합성

3.1 형태학적 합성의 목적

형태학적 분석 단계에서 컴파일된 형태학적 테이블을 기반으로 경제적으로 타당하고 작동이 신뢰할 수 있는 솔루션을 식별하는 것이 필요합니다.

3.2 전문가 평가 표

표 5: 기술 대상에 대한 전문가 평가 표.

요소 이름

기준에 따른 요소 평가

능률

간단

구현

경제

신뢰할 수 있음

V 1 1 - 강철;

V 1 2 - 알루미늄;

V 1 3 - 플라스틱

V 2 1 - 강철;

V 2 2 - 알루미늄;

V 2 3 - 황동;

V 4 1 - 피스톤;

V 4 2 - 유압;

차단 장치:

V 5 1 - 버튼;

V 5 2 - 접촉판;

기준의 가중치 적용:

효율성 - 0.3

구현 용이성 - 0.1

수익성 - 0.2

신뢰성 - 0.4

3.3 단일 기준 합성

"신뢰성" 기준에 따른 합성.

최선의 선택:

칼 재질: V 2 1 - 강철;

3.4 모든 기준에 의한 합성

표 #6: 모든 기준에 대한 종합 표.

최선의 선택:

커버 재질: V 1 3 - 플라스틱;

칼 재질: V 2 1 - 강철;

프레스 유형: V 4 1 - 피스톤;

차단 장치 유형: V 5 2 - 접촉판.

결론

이 과정에서는 커피 원두를 분쇄하는 균일성과 강도를 보장하기 위해 만들어진 자동화된 전기 커피 그라인더 시스템을 고려했습니다. 임팩트 전동 커피 그라인더 시스템의 특징은 고속으로 회전하는 칼을 사용하여 볶은 커피 원두를 분쇄하는 것입니다.

코스 작업 과정에서 시스템의 구성 및 기능 분석, 기능 및 물리적 분석, 형태 학적 분석 및 기술적 개체의 합성이 수행되었습니다. 고려 중인 시스템의 구성적 기능 및 흐름 기능적 구조가 컴파일되었습니다. 효율성, 구현 용이성, 경제성, 신뢰성과 같은 모든 기준에 대해 최적의 옵션을 찾을 수 있습니다. 결과적으로 시스템 분석 방법과 기존 시스템 및 기술 개체를 수정하고 새로운 것을 발명할 수 있는 새로운 설계 솔루션을 합성하는 방법에 대한 경험을 얻었습니다.

사용된 소스 목록

http://www.4analytics.ru/metodi-analiza/metod-ekspertnix-ocenok.html

http://www.coffeepedia.ru/%D0%9A%D0%BE%D1%84%D0%B5%D0%BC%D0%BE%D0%BB%D0%BA%D0%B0

http://coffeetime.ru/production/cook/2007-04-16-624/

Allbest.ru에서 호스팅

유사한 문서

    디자인 프로세스에 대한 지침으로 "기술적 개체 모델" 개념의 본질. 기술 개체의 진단 및 다중 요소 모델의 특성화. 특성 및 특성 연구, 설계된 시스템의 동작 예측.

    초록, 2009년 10월 13일 추가됨

    신뢰성 지표의 일반적인 특성. 신뢰성과 물체 품질 사이의 관계. 의 의미 리소스 테스트어떤 목적으로 수행되는지. "이벤트 트리"의 장점과 단점. 디자인 또는 기술의 현대화.

    제어 작업, 2011년 3월 1일 추가됨

    기술 개체의 라이프 사이클의 본질, 단계, 경계, 구조 및 기간, 복잡한 기술 시스템 설계에서의 역할. 콘텐츠 및 캐릭터 특성기술 개체의 설계, 생산 및 운영 단계.

    초록, 2009년 10월 13일 추가됨

    LLC "KINEF"의 개발 단계. 정유에 사용되는 기본 화학 공정. 시스템을 만드는 목적과 목적. 충격 펄스 센서. 저항 열전대의 작동 원리. 시스템 신뢰성 지표 결정.

    실습 보고서, 2015년 5월 26일 추가됨

    예비 배수 장치(UPSV)의 목적 및 흐름도. IWSU의 자동 제어 시스템의 기능 및 구조, 레벨 개발 및 장비 선택. 시스템의 신뢰성과 기술 및 경제적 효율성 계산.

    2013년 9월 29일 추가된 논문

    품질 관리 시스템에서 제품 신뢰성 문제의 위치. 표준화에 기반한 신뢰성 보증 시스템의 구조. 기술 시스템의 신뢰성을 평가하고 개선하는 방법. 전제 조건 현대 개발신뢰성 이론에 대해 연구합니다.

    초록, 2010년 5월 31일 추가됨

    인공 위험의 분석 및 평가를 위한 방법론, 기술적 개체의 기본 속성 및 신뢰성 매개변수를 평가하는 데 사용되는 수학적 공식, 실패 물리학 요소, 블록 다이어그램기술 시스템 및 계산의 신뢰성.

    학기 논문, 2017년 2월 15일 추가됨

    ILM1 산업용 회전 속도계 시스템의 신뢰성 및 성능에 대한 요구 사항 결정. 다양한 하위 시스템에 대한 안정성 요구 사항 배포. 신뢰성 방법을 기반으로 시스템의 신뢰성과 인공 위험에 대한 분석을 수행합니다.

    학기 논문, 2013년 5월 23일 추가됨

    운영시간에 따른 시스템 무고장 운영 확률의 변화 분석. 기술 시스템의 백분율 작동 시간 개념, 요소의 신뢰성 및 시스템 요소의 구조적 중복성을 증가시켜 증가를 보장하는 기능.

    테스트, 2010년 4월 16일 추가됨

    회전 드릴링 중 암석 파괴의 세부 사항. 로터리 드릴링 머신의 사용 범위, 분류 및 디자인 특징. 타악기 드릴링 머신. 수동 타악기로서의 착암기의 기능에 대한 설명.

지식 기반에서 좋은 작업을 보내는 것은 간단합니다. 아래 양식을 사용하세요

연구와 작업에 지식 기반을 사용하는 학생, 대학원생, 젊은 과학자들은 매우 감사할 것입니다.

http://www.allbest.ru/에서 호스팅

소개

1. 컨셉 디자인

1.1 엔티티 유형 정의

1.2 속성 정의 및 엔터티 유형과 연결

1.3 속성 도메인 정의

1.4 대체 및 기본 키 정보

2. 로직 설계

2.1 로컬 개념 데이터 모델을 로컬 논리 모델로 변환

2.2 정규화 규칙으로 모델 확인하기

2.3 사용자 트랜잭션 및 쿼리 실행에 대한 모델 유효성 검사

2.4 최종 엔터티 관계 다이어그램 구축

결론

중고 문헌 목록

소개

데이터베이스 - 전자 컴퓨터(컴퓨터)를 사용하여 이러한 자료를 찾고 처리할 수 있도록 체계화된 객관적인 형태로 제시된 일련의 독립적인 자료(기사, 계산, 규정, 법원 결정 및 기타 유사한 자료)입니다.

DBMS는 가장 효율적인 방법으로 수행하는 순차 테이블 스캔을 사용자에게 숨깁니다. 고도로 중요한 기능관계형 시스템은 데이터베이스 테이블에 대한 쿼리의 결과가 데이터베이스에 저장될 수 있거나 새로운 쿼리가 수행될 수 있는 테이블이기도 합니다. 디자인 컨셉 키

정보 시스템의 주요 목적은 궁극적으로 사용자에게 제공되는 세계와 그 안에서 일어나는 프로세스에 대한 정보를 저장하는 것입니다. 다양한 그룹의 사람들에게는 현실 세계의 특정 부분에만 관심이 있기 때문에 각각의 데이터는 정보 시스템특정 지역에 적용됩니다. 실제 시스템에서 그것을 설명하기 위해 연구해야 하는 부분을 주제 영역이라고 합니다.

완전한 주제 영역과 그 단편 간에 구별이 이루어지며 각 단편은 자체 주제 영역을 나타낼 수 있습니다. 예를 들어 대학의 경우 교육 부서, 회계, 인사 부서, 일정 관리국 등의 조각을 구별할 수 있습니다.

주제 영역을 설명하는 데 필요한 정보에는 사람, 개체, 문서, 이벤트, 개념 등에 대한 정보가 포함될 수 있습니다.

각 주제 영역은 주제 영역의 단일 보기로 특징지어지는 사용자 집합뿐만 아니라 개체를 사용하는 실제 시스템 및 프로세스의 요소인 개체 집합으로 특징지어집니다. 특히 회계의 경우 객체는 모든 종류의 문서입니다. 회계 프로세스 - 급여, 자재 회계, 은행 업무 회계 등 마지막으로이 단편의 사용자는 회계 직원, 금융 당국 직원, 회사 관리자 등입니다.

각 개체에는 정보 시스템에 저장된 특정 속성 집합이 있습니다. 데이터를 처리할 때 예를 들어 학생이나 교수진과 같은 동종 개체의 집합을 처리하고 각각에 대해 동일한 속성에 대한 정보를 기록해야 하는 경우가 많습니다. 동일한 속성 집합을 가진 개체 집합을 개체 클래스라고 합니다. 동일한 클래스의 개체에 대해 속성 집합은 동일하지만 각 개체에 대한 이러한 속성 값은 다를 수 있습니다.

종종 개체 클래스를 엔터티라고 합니다. 각 엔터티에는 속성이 있습니다. 속성은 인스턴스를 특징짓는 개체의 속성입니다. "학생" 엔터티는 "이름", "생년월일", "입학일" 등의 속성을 가질 수 있습니다. 따라서 엔터티는 동일한 유형(인스턴스)의 개별 개체 집합으로 정의할 수 있으며 모든 이러한 객체는 다릅니다. 즉, 속성 집합은 동일하지만 값이 다릅니다.

내 작업의 목적은 상품 키트 및 PC 구성 요소의 판매 및 배송을 기록하는 데이터베이스를 개발하는 것입니다. 또한 공급자와 수취인 간의 상품 이동을 기록하는 데 사용됩니다.

작업 작업:

항목 유형 정의

연결 유형 정의

속성을 정의하고 엔터티와 연결

속성 도메인 정의

대체 키 정의(속성)

엔터티 관계 다이어그램 만들기

로컬 개념 모델을 로컬 논리적 데이터 모델로 변환

정규화 규칙으로 모델 검증

사용자 트랜잭션에 대한 모델 검증 및 쿼리 실행

최종 "엔티티 관계" 다이어그램 작성

1. 컨셉 디자인

개념적(정보학적) 디자인 - 주제 영역의 의미론적 모델 구축, 즉 정보 모델가장 높은 수준의 추상화. 이러한 모델은 특정 DBMS 및 데이터 모델에 중점을 두지 않고 생성됩니다. "의미론적 모델", "개념적 모델" 및 "정보학적 모델"이라는 용어는 동의어입니다. 또한 "데이터베이스 모델" 및 "도메인 모델"이라는 단어(예: "개념적 데이터베이스 모델" 및 "개념적 도메인 모델")는 이러한 맥락에서 동등하게 사용될 수 있습니다. 이 현실에 대한 디자인 데이터베이스의 이미지.

개념적 데이터베이스 모델의 구체적인 형식과 내용은 이를 위해 선택한 형식적 장치에 의해 결정됩니다. ER 다이어그램과 유사한 그래픽 표기법이 일반적으로 사용됩니다.

가장 일반적인 개념적 데이터베이스 모델에는 다음이 포함됩니다.

정보 객체 또는 주제 영역의 개념 및 이들 간의 관계에 대한 설명.

무결성 제약 조건에 대한 설명, 즉 유효한 데이터 값과 그 사이의 관계에 대한 요구 사항.

1.1 엔티티 유형 정의

엔터티는 구별 가능한 모든 개체(다른 개체와 구별할 수 있는 개체)로, 데이터베이스에 저장해야 하는 정보입니다. 엔터티는 사람, 장소, 비행기, 비행, 취향, 색상 등이 될 수 있습니다. 엔티티 유형 및 엔티티 인스턴스와 같은 개념을 구별하는 것이 필요합니다.

엔터티는 실제 개체, 프로세스, 현상 또는 개체에 대한 아이디어의 일부 추상화로서 데이터베이스에 저장해야 하는 정보인 집합적 개념입니다.

엔티티 유형 및 엔티티 인스턴스와 같은 개념을 구별하는 것이 필요합니다. 엔터티 유형의 개념은 전체적으로 작동하는 동질적인 사람, 개체, 이벤트 또는 아이디어의 집합을 나타냅니다. 엔터티 인스턴스는 집합의 특정 항목을 참조합니다. 예를 들어 엔티티 유형은 CITY일 수 있고 인스턴스는 모스크바, 키예프 등이 될 수 있습니다.

엔터티에는 세 가지 유형이 있습니다. 핵심, 연관(연관) 및 특성(특징)입니다. 또한 지정의 하위 집합도 연관 엔터티 집합에서 정의됩니다. 이제 엔터티의 유형을 정의하겠습니다.

핵심 엔터티.

핵심(강한) 엔티티는 다른 것들과 독립적인 엔티티입니다. 핵심 엔티티는 연관, 특성 또는 지정이 될 수 없습니다(아래 참조).

협회.

연관 엔티티(또는 연관)는 두 엔티티 간의 다대다 관계를 표현합니다. 완전히 독립적인 존재입니다. 예를 들어, 엔티티 MAN과 WOMAN 사이에는 연관 엔티티 MARRIAGE로 표현되는 연관 관계가 있습니다.

특성.

특성 엔터티는 약한 엔터티라고도 합니다. 일대다 및 일대일 관계로 더 강한 엔터티와 관련됩니다. 특성 엔터티는 다른 엔터티를 설명하거나 구체화합니다. 그녀는 그녀에게 완전히 의존하며 후자의 실종과 함께 사라집니다.

지정.

표기법은 다른 엔터티가 다대일 또는 일대일 방식으로 관련된 엔터티입니다. 지정은 특성과 달리 독립적인 개체입니다. 예를 들어, 엔티티 Faculty는 학생이 연구소의 이 부서에 속하는 것을 나타내지만 완전히 독립적입니다.

링크 유형 정의

연결두 엔터티 유형 간에 설정된 그래픽 연결입니다. 엔터티와 마찬가지로 링크는 유형 개념이며 연결된 두 엔터티 유형의 모든 인스턴스는 설정된 연결 규칙의 적용을 받습니다. 따라서 엔터티 유형 간의 관계 유형에 대해 이야기하고 엔터티 유형의 인스턴스 간에 설정된 관계 유형의 인스턴스에 대해 이야기하는 것이 더 정확합니다. 여기에서 논의된 ER 모델 버전에서 이 연관은 항상 이진적이며 둘 사이에 존재할 수 있습니다. 다른 유형엔터티 또는 엔터티 유형과 자체 사이(재귀적 관계). 모든 연결에서 두 개의 끝이 구별되며(관련 엔터티의 기존 쌍에 따라) 각 끝은 연결 끝의 이름, 연결 끝 정도(이 유형의 엔터티의 인스턴스 수 이 연결 유형의 각 인스턴스에 있어야 함), 연결의 바인딩(즉, 주어진 엔터티 유형의 인스턴스가 주어진 관계 유형의 일부 인스턴스에 참여해야 하는지 여부).

커뮤니케이션은 형식으로 제공됩니다. 동시에 엔티티와의 "도킹"장소에서 다음이 사용됩니다.

엔터티가 관계에서 엔터티의 많은 인스턴스를 사용할 수 있거나 사용해야 하는 경우 엔터티 직사각형에 대한 3점 항목입니다.

엔터티의 한 인스턴스만 관계에 참여할 수 있거나 참가해야 하는 경우 단일 지점 항목입니다.

필수 링크 끝은 실선으로 표시되고 선택적 링크 끝은 파선으로 표시됩니다.

엔터티 TICKET과 PASSENGER 간의 관계는 티켓과 승객을 연결합니다. "for"라는 이름으로 연결이 종료되면 동일한 승객과 하나 이상의 티켓을 연결할 수 있으며 각 티켓은 승객과 연결되어야 합니다. 이름이 "has"인 관계의 끝은 각 티켓이 한 명의 승객에게만 속할 수 있으며 승객이 하나 이상의 티켓을 가질 필요가 없음을 나타냅니다.

쌀. 하나. 링크 유형 예

· 각 TICKET은 한 명의 승객만을 위한 것입니다.

· 각 승객은 하나 이상의 티켓을 가질 수 있습니다.

재귀 관계

다음 예(그림 2)는 엔티티 MAN을 자신과 연결하는 재귀 링크를 보여줍니다. "아들"이라는 이름과의 연결의 끝은 여러 사람이 한 아버지의 아들이 될 수 있다는 사실에 의해 결정됩니다. "아버지"라는 이름과의 연결의 끝은 모든 사람이 아들을 가져야 하는 것은 아니라는 것을 의미합니다.

쌀. 2. 재귀 관계 유형의 예

묘사된 도표의 간결한 구두 해석은 다음과 같습니다:

모든 MAN은 단 한 명의 MAN의 아들입니다.

각 MALE은 한 명 이상의 MALE의 아버지가 될 수 있습니다.

테이블 간의 관계 유형

커뮤니케이션을 통해 주제 영역에서 개체 간의 관계를 모델링할 수 있습니다.

연결에는 4가지 유형이 있습니다.

1. " 1-1" - 엔터티 A의 모든 인스턴스는 엔터티 B의 하나의 인스턴스에만 해당하며 그 반대의 경우도 마찬가지입니다.

주어진 학생은 하나의 특성만 가질 수 있으며 해당 특성은 단일 학생을 나타냅니다.

2. " 일대다" - 엔터티 A의 모든 인스턴스는 엔터티 B의 0, 1 또는 여러 인스턴스에 해당하지만 엔터티 B의 모든 인스턴스는 엔터티 A의 하나의 인스턴스에만 해당합니다.

학생은 많은 점수를 받습니다. 주어진 학년은 한 학생에게만 속합니다.

3. " 다대일" - 엔터티 A의 모든 인스턴스는 엔터티 B의 하나의 인스턴스에만 해당하지만 엔터티 B의 모든 인스턴스는 엔터티 A의 0, 1개 이상의 인스턴스에 해당합니다.

교사는 한 사무실에서만 일하지만 사무실은 여러 교사에게 할당될 수 있습니다.

4. " 다대다" - 엔터티 A의 모든 인스턴스는 엔터티 B의 0, 1개 이상의 인스턴스에 해당하고 엔터티 B의 모든 인스턴스는 엔터티 A의 0, 1개 이상의 인스턴스에 해당합니다.

학생 Ivanov는 여러 교사로부터 배웁니다. 그리고 각 교사는 많은 학생들과 함께 일합니다.

1.2 속성 정의 및 엔티티 유형과 연결

엔터티의 속성은 엔터티의 상태를 명확히, 식별, 분류, 수량화 또는 표현하는 역할을 하는 모든 세부 사항입니다. 속성 이름은 엔터티 이름 아래 엔터티 사각형에 배치되고 소문자로 표시되며 예를 들어 있을 수 있습니다.

지정된 속성을 갖는 PERSON 엔티티 유형의 예가 (그림 3)에 나타나 있으며 기술적인 관점에서 ER 모델의 엔티티 유형 속성은 의 관계 속성과 유사합니다. 관계형 모델데이터. 두 경우 모두 명명된 속성을 도입하면 이름이 ER 모델의 경우 엔터티 유형의 이름과 같거나 이름이 있는 일부 유형 데이터 구조가 도입됩니다. 관계변수관계형 모델에서 이 유형 구조 뒤에는 엔티티 유형의 모든 인스턴스 또는 관계의 모든 튜플이 와야 합니다.

쌀. 삼.속성이 있는 엔터티 유형의 예

ER 모델에서 엔티티 유형 속성을 정의할 때 속성 도메인을 지정하는 것은 가능하지만 선택 사항입니다(아래 참조). 속성의 "약한" 정의의 가능성을 야기한 원인에 대해 논의해 보겠습니다. 먼저 개념적 데이터베이스 스키마를 구축하기 위해 시맨틱 데이터 모델이 사용되며, 이러한 스키마는 특정 DBMS에서 지원하는 관계형 데이터베이스 스키마로 변환됩니다.

위에서 언급했듯이 엔터티 유형을 정의할 때 엔터티의 각 인스턴스가 동일한 엔터티의 다른 인스턴스와 구별되도록 해야 합니다. 엔티티는 실제 또는 표현된 객체의 추상화이기 때문에 외부 세계, 엔티티 유형에 대한 후보를 선택할 때 이 요구 사항을 이미 염두에 두어야 합니다. 엔티티 고유 식별자는 동일한 유형의 다른 엔티티 인스턴스와 엔티티 인스턴스를 고유하게 구별하는 속성, 속성 조합, 관계, 관계 조합 또는 관계 및 속성 조합일 수 있습니다. 몇 가지 예를 들어보겠습니다. 그림 4는 서점 데이터베이스에서 사용하기에 적합한 BOOK 엔터티 유형을 보여줍니다. 출판사에서 책을 출판하면 고유 번호인 ISBN이 지정됩니다. isbn 속성의 값은 재고 도서 배치를 고유하게 식별할 것입니다. 또한 속성의 조합도 고유 식별자로 적합함은 물론<автор, название, номер издания, издательство, год издания>.

쌀. 네인스턴스가 속성으로 식별되는 엔티티 유형

(그림 5)에서 다이어그램에는 두 가지 관련 엔터티 유형이 포함됩니다. 성인 1인당 1개만 소지할 수 있으며 여권 1개당 성인 1명만 소지할 수 있습니다. 그런 다음 여권과 사람의 연결은 성인을 고유하게 식별합니다. 즉, 대략적으로 말하면 여권은 성인을 식별합니다. 아직 누구에게도 발급되지 않은 여권이 있을 수 있기 때문에 이 연결은 PASSPORT 엔터티에 대한 고유 식별자가 아닙니다.

쌀. 5연관에 의해 인스턴스가 식별되는 엔티티 유형

(그림 6)에서 다이어그램은 세 가지 관련 엔터티 유형을 포함합니다. 교수들은 여러 학문 분야에 대한 지식을 가지고 있습니다. 각 분야의 강의는 여러 교수에게 제공됩니다. 즉, PROFESSOR와 DISCIPLINE 엔터티 간에 다대다 관계가 정의됩니다. 각 교수는 자신이 사용할 수 있는 모든 분야의 과정을 준비할 수 있습니다. 각 분야는 여러 교육 과정에 전념할 수 있습니다. 그러나 각 교수는 자신이 사용할 수 있는 모든 분야에서 하나의 과정만 가르칠 수 있으며 각 과정은 한 분야에만 전념할 수 있습니다. 따라서 COURSE 엔터티 유형의 각 인스턴스는 PROFESSOR 엔터티의 인스턴스와 DISCIPLINE 엔터티의 인스턴스, 즉 COURSE 엔터티 측면에 끝 이름이 PREPARED 및 DEDICATED인 링크 쌍에 의해 고유하게 식별됩니다. PROFESSOR 및 DISCIPLINE 엔터티는 링크로 식별되지 않습니다.

쌀. 6. 관계의 조합으로 인스턴스가 식별되는 엔티티 유형

마지막으로(그림 7)은 고유 식별자가 속성과 관계의 조합인 엔터티 유형의 예를 보여줍니다. 모든 사람은 자녀를 가질 수 있고 모든 사람에게는 아버지가 있습니다. 그런 다음 같은 시기에 태어난 쌍둥이에게 같은 이름이 부여되지 않는다고 가정하면 HUMAN 엔터티 유형의 고유 식별자는 속성의 조합이 될 수 있습니다.

쌀. 7. 속성과 관계의 조합으로 인스턴스를 식별하는 엔티티 유형

1.3 속성 도메인 정의

도메인관계형 데이터 모델에서 데이터 유형, 즉 유효한 값 집합입니다.

데이터 유형의 개념은 기본입니다. 모든 값, 모든 변수, 모든 매개변수, 모든 읽기 문, 특히 모든 관계형 속성은 한 유형 또는 다른 유형입니다.

예는 "정수"(모든 정수의 집합), "문자열"(모든 문자열의 집합), "부품 번호"(모든 부품 번호의 집합) 등이 될 수 있습니다. 관계 유형이 "정수"인 경우 이 속성의 모든 값은 "정수" 집합에 속하고 다른 값에는 속하지 않음을 의미합니다.

수학과 유사하게 데이터 유형은 다음과 같이 나뉩니다. 스칼라그리고 비 스칼라. 비 스칼라 유형의 값(비 스칼라 값)에는 집합이 있습니다. 사용자에게 보이는구성 요소 및 스칼라 유형의 값(스칼라 값)에는 하나가 없습니다. 비 스칼라 유형의 예로는 관계 유형 및 튜플 유형이 있습니다. 스칼라 유형의 예는 "정수" 유형입니다.

컴퓨터에서 데이터베이스 시스템 구현의 제한 사항은 유형 정의에 대한 몇 가지 규칙을 부과합니다. 따라서 이론적으로 INTEGER 유형은 집합입니다. 가능한 모든정수이지만 실제로 INTEGER는 다음을 수행하는 모든 정수의 집합입니다. 고려하여 제시할 수 있다 컴퓨터 시스템 (물론 모든 컴퓨터 시스템에서 표현할 수 있는 가능성을 초과하는 그러한 정수가 있기 때문입니다).

특정 컴퓨터 시스템에서 해당 유형의 값을 물리적으로 표현하기 위한 형식(논리적 개념)과 형식을 구분해야 합니다. 유형은 레벨을 나타냅니다. 논리적 모델, 그리고 값의 물리적 표현 - 수준까지 구현. 예를 들어, "문자열" 유형에 대해 정의된 작업은 특정 구현에서 숫자가 물리적으로 문자열로 표현되더라도 "숫자" 유형에 대해 의미가 없습니다. "날짜" 유형의 값은 종종 물리적으로 실수로 표시되지만 "숫자" 유형에 대해 의미가 있는 대부분의 연산은 "날짜" 유형에 대해 의미가 없습니다.

관계형 데이터 모델은 다음을 제외하고 사전 정의된 유형의 필수 지원을 규정하지 않습니다. 부울 유형(BOOLEAN), 작업을 수행할 때 없이는 불가능합니다. 일반적으로 시스템에서 특정 유형 집합을 지원하며 다른 유형은 사용자가 추가로 구성할 수 있습니다.

1.4 대체 키 및 기본 키 정보

변태개인 키- 관계형 데이터 모델에서 주요 키(또는 기본 키)로 선택된 관계의 잠재적 키 중 하나.

관계에 단일 후보 키가 있는 경우 기본 키이기도 합니다. 후보 키가 두 개 이상인 경우 그 중 하나를 기본 키로 선택하고 나머지 키를 " 대안".

이론의 관점에서, 관계의 모든 잠재적 키는 동일합니다. 즉, 동일한 속성을 갖습니다. 독창성그리고 미니멀리즘. 그러나 기본 키는 일반적으로 다른 측면에서 외래 키를 생성하거나 클러스터형 인덱스를 생성하는 것과 같은 특정 실용적인 목적에 가장 편리한 후보 키에서 선택됩니다. 따라서 기본 키는 일반적으로 가장 작은 크기(물리적 저장소) 및/또는 가장 적은 속성을 포함하는 키를 선택합니다.

1.6 엔티티 관계 다이어그램 작성

2. 논리 설계

논리적 데이터베이스 설계 모델을 구성하는 프로세스를 나타냅니다. 정보 구조선택한 정보 조직 체계의 요구 사항에 따라 실현 가능한 기업. 그러나 생성된 논리적 모델은 특정 DBMS의 기능 및 기타 물리적 구현 조건에 의존하지 않습니다.

2.1 로컬 개념 데이터 모델을 로컬 논리 모델로 변환

1. 첫 번째 단계는 다대다 관계를 제거하는 것입니다. 이러한 관계는 엔티티 "Kit"과 "Customer Firm" 사이에 존재합니다. 중간 엔터티 "List"를 도입하여 이러한 연결을 끊자.

2. 복잡한 링크 제거. 복잡한 관계는 세 가지 이상의 엔터티 유형이 참여하는 관계입니다. 내 작업에는 그런 연결이 없습니다.

3. 재귀 링크 제거. 재귀적 관계 - 엔터티가 실패와 상호 작용하는 관계. 내 작업에는 그런 연결이 없습니다.

4. 속성이 있는 링크 삭제.

5. 내 작업에서 여러 속성을 제거하면 하나의 여러 속성이 있습니다 - 전화. "받는 사람의 전화"를 "받는 사람의 집 전화"와 "받는 사람의 휴대 전화"로 나눕니다. "공급자 전화"에 " 휴대전화공급업체" 및 "공급업체 집 전화번호".

6. 중복 연결 제거. 내 작업에는 그런 연결이 없습니다.

2.2 정규화 규칙으로 모델 검증

관계형 데이터베이스 설계 기술은 관계 속성 간의 기능적 종속성 분석을 기반으로 하는 정규화 이론과 관련이 있습니다. 기능적 종속성의 개념은 관계형 데이터베이스 정규화 이론의 기본입니다. 기능적 종속성은 고려 중인 주제 영역에서 개체와 속성 간의 안정적인 관계를 정의합니다. 그렇기 때문에 주어진 주제 영역에 특정한 기능적 종속성을 지원하는 프로세스가 디자인 프로세스의 기반이 됩니다.

관계형 데이터베이스 이론에서 일반적으로 다음과 같은 정규 형식 시퀀스가 ​​구별됩니다.

1. 1 일반형

2. 2 일반형

3. 3 정규형

제1정규형(1NF)

관계 변수는 관계의 유효한 값에서 각 튜플이 각 속성에 대해 정확히 하나의 값을 포함하는 경우에만 제1정규형(1NF)입니다.

관계형 모델에서 관계는 관계 개념의 정의에 따라 항상 첫 번째 정규 형식입니다. 다양한 테이블은 관계의 올바른 표현이 아닐 수 있으며 따라서 1NF에 없을 수 있습니다.

제2정규형(2NF)

관계 변수는 첫 번째 정규 형식이고 키가 아닌 모든 속성이 후보 키에 환원 불가능하게(기능적으로 완전) 종속되는 경우에만 두 번째 정규 형식입니다.

제3정규형(3NF)

관계 변수는 제2 정규형이고 키 속성에 대한 키가 아닌 속성의 이행적 기능 종속성이 없는 경우에만 제3 정규형입니다.

2.3 사용자 트랜잭션 및 쿼리 실행에 대한 모델 유효성 검사

1. 지정된 소스의 사용 가능한 구성 요소에 대한 정보

액세서리를 선택하십시오. 구성 요소의 이름, 회사 공급업체. 공급자 이름, 액세서리, 공급자 번호

FROM 액세서리, 공급업체

WHERE 공급자 회사, 공급자 회사 이름 "AMD"

그리고 공급자 회사, 공급자 회사 번호 = 부품, 공급자 회사 번호;

2. 특정 고객이 주문한 키트에 대한 정보와 수령인의 성명

SELECT 키트, 키트 이름, 목록, 키트 번호, 고객 회사 번호, 고객 회사, 고객 회사 이름, 받는 사람, 받는 사람 이름

FROM 세트, 목록, 고객, 수신자

WHERE 고객사, 고객사명 - "인터콤"

AND 목록 키트 번호 키트. 키트 번호 AND 목록, 고객 회사 번호=고객 회사, 고객 회사 번호 AND 받는 사람, 받는 사람 번호=키트 받는 사람 번호;

2.4 최종 차트 작성" 에센스 연결"

결론

이 과정에서 나는 컴퓨터 살롱의 작업을 자동화하기 위한 데이터베이스를 개발했습니다. 초기 단계에서는 사용자가 가장 관심을 가지고 있는 객체를 결정해야 하는 도메인 모델을 만들었습니다. 이를 위해 내가 만든 상세 설명주제 영역과 이러한 객체 사이에 존재하는 관계에 대해 내 모델에서 복잡하고 재귀적이며 속성과의 관계와 같은 유형의 관계가 있는지 확인하고 다대다 관계를 나누고 엔터티 유형 및 속성 유형 및 이 데이터를 기반으로 다이어그램 엔터티 관계 구축

레벨 2에서는 정규화 규칙을 사용하여 링크 확인 및 모델 유효성 검사를 수행했습니다. 내 데이터 모델은 첫 번째 및 두 번째 정규 형식이었고, 전이 종속성을 찾아 다른 엔터티(목록)로 전송하여 모델을 세 번째 정규 형식으로 가져왔습니다. 사용자 트랜잭션 및 쿼리 실행에 대해 모델을 검증한 다음 최종 엔티티 관계 다이어그램을 작성했습니다. 내가 한 일을 바탕으로 내 데이터베이스가 컴퓨터 살롱 작업에 좋은 도움이 될 것이라고 말할 수 있습니다.

중고 문헌 목록

1. 데이터베이스. 교과서 A.D. 호모넨코

2. 와이스코스 J. 효과적인 작업 MS 액세스 2000

3. 위키피디아

4. Date K. J. 데이터베이스 시스템 소개

Allbest.ru에서 호스팅

...

유사한 문서

    연간 7000톤의 총 용량을 가진 도료, 바니시 및 솔벤트 생산을 위한 복합 단지 설계를 위한 초기 데이터. 베이스라인 데이터 및 일반 정보기술에 대해. 생산의 기본 기술 계획에 대한 설명.

    학기 논문, 2009년 2월 17일 추가됨

    자동화 설계 단계의 특성. Basiq Norma 1 및 Norma 2 프로그램을 사용하여 여성용 데미 시즌 코트의 기초 재료 소비율을 계산하는 방법론 및 알고리즘 컴퓨터를 사용한 데이터 처리 자동화의 특징.

    학기 논문, 2010년 5월 6일 추가됨

    전기 모터 선택 및 2단 웜 기어박스 설계. 설계 기준: 기어박스 치수 및 재료 선택. 고속 및 저속 전송 계산. 웜 및 웜 휠의 건설. 변속기 레이아웃.

    학기 논문, 2012년 1월 12일 추가됨

    가금류 집 설계를 위한 초기 데이터 편집. 열 전달에 필요한 열 저항 결정. 개별 바닥 구역의 면적 계산. 둘러싸는 구조를 통한 열 손실 계산. 열 공기 체제 및 공기 교환 계산.

    학기 논문, 2010년 9월 10일 추가됨

    규산염 벽돌에 대한 기본 정보. 석회-실리카 바인더 생산. 원료 혼합물을 감쇠하기 위한 사일로. 재료의 오토클레이브 처리 과정. 원료의 필요성 계산. 재료의 입력 제어. 창고 설계 계산.

    2014년 1월 27일에 추가된 논문

    기계 생산 공장의 설계 및 재건 규칙: 기계 조립 생산 설계에 대한 일반 정보, 작업 초안 및 작업 문서에 대한 설명, 설계된 부품 제조 현장의 내부.

    테스트, 2008년 12월 28일 추가됨

    철근 콘크리트 제품 ​​및 콘크리트 혼합물 공장 제품의 특성. 콘크리트 혼합물 준비 프로그램의 생산성 계산. 기술 장비 선택. 자재 저장 재고량 결정 및 창고 유형 선택.

    학기 논문, 2015년 6월 11일 추가됨

    컴퓨터 지원 의류 디자인 시스템의 기능. 의류 모델의 예술적 디자인. 인물의 인체 측정 분석. 모델 구조를 설계하는 방법. 일련의 모델 개발, 패턴 개발 및 소비율 결정.

    논문, 2009년 6월 26일 추가됨

    스윙 리프트의 구동 장치 역할을 하는 기계 장치의 작동 조건. 설계를 위한 엔진, 드라이브의 운동학적 계산. 웜 기어 재료 선택 및 허용 응력 결정. 샤프트 및 베어링 계산.

    학기 논문, 2011년 6월 16일 추가됨

    시스템 및 급수 방식 선택의 정당화, 네트워크의 수력 계산 및 계량기 선택. 필요한 압력의 결정. 하수도 시스템 설계 규범, 내부 및 야드 네트워크 계산. 재료 및 장비 사양.

개념 설계의 개념은 IS 설계의 초기 단계를 말하며 GOST 34에 따른 AS 개발의 1-3단계 또는 요구사항 정의에서 라이프 사이클 모델의 설계까지의 단계에 대략 해당합니다.

IP에 대한 요구사항의 정의는 이 시스템이 개발될 목적의 정의에 선행합니다. IS 목표는 주제 영역의 경계를 정의하며 목표 설정의 관점에서 개체, 속성 및 관계가 중요하고 IS에 표시될 대상 영역(주제 영역에 대한 정보 - 소프트웨어 정보) . IS의 목적은 또한 시스템이 제공할 사용자와 정보가 필요한 정보를 결정합니다(이는 사용자의 요구에 대한 정보 - PP 정보). 소프트웨어 정보(주제 영역의 객관적인 반영)와 소프트웨어 정보(부분적으로 사용자의 주관적인 인식을 반영함)는 개념적 모델을 구축하는 데 똑같이 필요하고 중요합니다. 14 7 . 때때로 두 번째 항은 현재 및 예측 가능한 적용을 고려하여 개념적 모델에서 우선합니다. 이렇게 하면 시스템을 더 빠르고 쉽게 만들 수 있습니다. 그러나 이러한 시스템은 형식화되지 않고 변경되며 예측하지 못한 작업 및 요청을 처리하는 데 적합하지 않은 것으로 판명되었습니다. 시스템에서 소프트웨어 정보를 적절하게 반영하면 필요한 유연성과 변화하는 조건에 대한 적응성을 제공합니다.

영형 개념 설계의 일반적인 계획:

그림의 계획. 16은 디자인의 두 단계를 나타냅니다. 주제 영역 및 사용자의 응용 작업에 대한 정보 수집 및 의미 있는 분석; 개념적 데이터 분석 및 개념적 모델 합성.

첫 번째 단계는 측정 또는 관찰의 결과로 얻을 수 있는 주제 영역에 대한 데이터 수집, 보고서 및 문서 연구, 전문가 조사 및 다음을 사용하여 해결해야 하는 작업 목록 식별 개발된 시스템. 결과 정보는 다소 주관적일 수 있습니다. 객관성을 높이기 위해 전문가 평가 방법이 사용되며 정보 중복을 제거하고 모순과 모호성을 식별하는 등 의미있는 분석이 수행됩니다.

IS 모델 및 설계 방법

현대 정보 시스템 개발의 주요 특징은 복잡성의 집중입니다. 초기 단계요구 사항 분석 및 시스템 사양 설계. 시스템 요구 사항의 모호함과 불완전성, 해결되지 않은 문제 및 분석 및 설계 단계에서 발생한 오류는 후속 단계에서 어렵고 종종 해결되지 않는 문제를 일으키고 궁극적으로 전체 작업의 실패로 이어집니다.

두 가지 활동 영역이 IS 설계와 직접적으로 관련되어 있습니다. 1) 특수 개발 도구를 사용하여 기성 소프트웨어 및 하드웨어 구성 요소를 기반으로 하는 특정 조직의 IS 실제 설계; 2) 많은 특정 정보 시스템의 개발에서 재사용을 지향하는 언급된 IS 구성요소 및 도구의 설계. 여덟

"시스템 통합"이라는 용어는 첫 번째 방향을 지정하는 데 사용됩니다. 이 경우 IS 개발자는 시스템 엔지니어링 분야의 전문가여야 하며, 국제 표준, 정보 기술 및 소프트웨어 제품 개발 현황 및 동향, 자체 응용 프로그램 개발 도구(CASE-tools) 및 관련 주제 영역의 전문가와 협력하여 자동화된 응용 프로그램 프로세스에 대한 인식 및 분석을 준비합니다.

두 번째 방향은 설계 솔루션, 프로그래밍 기술, 운영 체제 등의 분석 및 합성 방법에 대한 지식을 기반으로 하는 모델, 방법, 알고리즘, 프로그램과 같은 IS 기능 구현을 위한 수학적 및 소프트웨어 개발과 더 관련이 있습니다.

조사 단계와 후속 단계에서 사양을 공식화하는 하나 이상의 방법론을 기반으로 얻은 결과를 수정하고 제시하는 특정 분야를 고수하는 것이 좋습니다. 수행자와 고객이 요구 사항, 제한 사항 및 결정을 명확하게 이해하려면 공식화가 필요합니다.

개념 설계에서는 여러 사양이 사용되며 그 중 정보의 변환, 저장 및 전송을 위한 모델이 중심적인 위치를 차지합니다. 조직의 설문 조사를 포함하여 주제 영역을 연구하는 과정에서 얻은 모델은 기능의 모델입니다.IS를 개발하는 과정에서 모델은 일반적으로 상당한 변화를 겪고 최종 형태는 이미 설계된 IS의 모델로 간주됩니다.

기능적, 정보적, 행동적 및 구조적 모델이 있습니다 9 . 시스템의 기능 모델은 시스템이 수행하는 기능 세트를 설명합니다. 정보 제공 모델은 데이터 구조(구성 및 관계)를 반영합니다. 행동 모델은 정보 프로세스(기능의 역학)를 설명하며 시스템 상태, 이벤트, 한 상태에서 다른 상태로의 전환, 전환 조건, 일련의 이벤트와 같은 범주를 포함합니다. 구조 모델은 시스템의 형태(구성), 즉 하위 시스템의 구성, 관계를 특성화합니다.

따라서 기능("무엇을 해야 합니까?" 질문에 응답), 초기 데이터("무엇을 해야 합니까?"), 제약(시간, 재정 및 물질적 자원, 규제 문서 또는 비즈니스 규칙 등), 구현 수단("무엇을 할 것인가?")과 결과("무엇을 할 것인가?")는 계획된 IS를 설명합니다.

모델을 만들고 표현하는 방법에는 여러 가지가 있으며, 모델 유형에 따라 다릅니다. 기본은 구조 분석입니다. 시스템을 연구하는 방법으로 일반적인 개요로 시작한 다음 자세히 설명하여 레벨 수가 증가하는 계층 구조를 형성합니다. 가장 일반적인 모든 구조적 접근 방법론은 여러 일반 원칙을 기반으로 합니다. 기본 원칙은 다음과 같습니다.

    "분할 및 정복"의 원칙 - 복잡한 문제를 이해하고 해결하기 쉬운 많은 작은 독립적인 작업으로 나누어 해결하는 원칙.

    계층적 순서의 원칙 - 조직의 원칙 구성 부품각 수준에 새로운 세부 사항이 추가된 계층적 트리 구조로 문제를 해결합니다.

두 가지 기본 원칙을 선택한다고 해서 나머지 원칙이 부차적이라는 의미는 아닙니다. 그 중 어느 것도 무시하면 예측할 수 없는 결과(전체 프로젝트의 실패 포함)로 이어질 수 있기 때문입니다. 이러한 원칙의 주요 내용은 다음과 같습니다.

    추상화의 원리 - 시스템의 필수 측면을 강조하고 비필수적 요소에서 추상화합니다.

    공식화의 원칙 - 문제를 해결하기 위한 엄격한 방법론적 접근이 필요합니다.

    일관성의 원칙 - 요소의 유효성과 일관성에 있습니다.

    데이터 구조화의 원칙 - 데이터는 구조화되고 계층적으로 구성되어야 합니다.

현재 약 90여종의 구조시스템해석이 알려져 있으며, 이를 모델 구축 순서(기능 또는 정보 모델링의 우선순위 선언)에 따라 학교(모델링 소프트웨어 시스템 또는 일반 시스템용)로 분류할 수 있다. 대상 시스템의 유형(정보 시스템 또는 실시간 시스템) 10 . 이러한 풍부한 방법에도 불구하고 거의 모든 방법이 세 가지 도구 그룹을 사용합니다.

    DFD(데이터 흐름 다이어그램) - 시스템이 수행해야 하는 기능을 설명하는 데이터 흐름 다이어그램 또는 SADT(구조적 분석 및 설계 기술) 다이어그램입니다.

    ERD(Entity-Relationship Diagrams) - 데이터 간의 관계를 모델링하는 엔터티-관계 다이어그램.

    STD(상태 전환 다이어그램) - 시스템의 시간 종속 동작(실시간 측면)을 모델링하는 상태 전환 다이어그램입니다.

이러한 모델 외에도 구조 설계 단계에서 구조 맵 기술은 모듈(Constantine 구조 맵)과 모듈의 내부 구조(Jackson 구조 맵) 간의 관계를 설명하는 데 사용됩니다.

다양한 구조 분석 간의 가장 중요한 차이점은 기능 모델링의 방법과 수단에 있습니다. 정보 및 행동 모델링의 경우 현재 각각 ERD 및 STD에 대한 대안이 실질적으로 없기 때문입니다. 다음으로, 위의 설계 기법과 관련된 기본 개념을 고려하십시오.

리뷰 강의 요약

전공의 학생들을 위해
T1002 "정보 기술 소프트웨어"

(L.V. Rudikova, Ph.D., 부교수)

질문 31. DBMS 아키텍처. 관계형 데이터 모델

1. 데이터베이스의 개념입니다.

2. 3계층 데이터베이스 아키텍처.

3. 데이터베이스 수명 주기.

4. DBMS 아키텍처.

5. 관계형 데이터 모델.

6. 관계형 데이터베이스 설계.

7. 정상적인 형태처지.

8. 관계 대수학.

1. 데이터베이스의 개념.

데이터베이스 시스템은 여러 응용 프로그램 간에 데이터를 공유할 수 있는 컴퓨터 기반 정보 시스템입니다.

정보시스템 - 데이터를 정리하고 정보를 발행하는 자동 시스템.

정보 및 제어 시스템 - 제공하는 시스템 정보 지원관리.

데이터 - 흩어진 사실.

정보 - 조직화되고 처리된 데이터.

아래에 데이터 베이스 하나 이상의 응용 시스템에서 처리할 수 있는 데이터(정보)의 상호 관련된 기본 그룹 집합을 나타냅니다. 데이터베이스 시스템 데이터베이스로 구성됩니다. 라는 범용 소프트웨어 데이터베이스 관리 시스템(DBMS) , 데이터베이스를 관리하는 역할을 합니다. 적절한 장비와 사람.

각 DBMS는 다음 요구 사항을 충족해야 합니다.

· 사용자에게 새로운 데이터베이스를 생성하고 정의할 수 있는 기능 제공 스키마(논리적 데이터 구조)특별한 언어를 사용하여 데이터 정의 언어; 동일한 데이터의 여러 표현을 지원합니다.

· 허락하다 " 요구» 데이터 및 수정 쿼리 언어, 또는 데이터 조작 언어; 서로 다른 응용 프로그램 간의 데이터 통합 ​​및 공유를 허용합니다.

· 기가바이트 이상으로 측정된 초대형 데이터 어레이의 저장을 장기간 지원하여 우발적인 손상 및 무단 사용으로부터 보호합니다. 데이터 보안 및 무결성 보장

· 많은 사용자의 데이터에 대한 액세스를 동시에 제어합니다. 한 사용자의 요청이 다른 사용자의 요청에 미치는 영향을 배제하고 데이터를 손상시킬 수 있는 동시 액세스를 방지합니다. 보증 관리 병렬 액세스데이터에.

데이터베이스 시스템은 다음 구성 요소로 구성됩니다.

· 사용자, 즉 데이터를 사용하는 사람들.

· 응용 프로그램, 즉 시스템에서 데이터를 필요로 하는 사용자 프로그램.

· DBMS - 데이터에 대한 액세스를 관리하고 데이터베이스 시스템의 지정된 기능을 제공하는 소프트웨어입니다.

· 데이터, 즉 파일에 저장된 문자열

· 호스트 시스템은 파일이 저장되는 컴퓨터 시스템입니다. 데이터 행은 호스트 시스템에서 액세스합니다. DBMS의 역할은 호스트 시스템의 파일 관리 시스템 기능의 사용을 허용하는 쿼리를 생성하는 것입니다. 다양한 응용. DBMS는 호스트 시스템 소프트웨어 위에 구축된 추가 소프트웨어 계층입니다.

따라서 데이터베이스가 있는 시스템은 다음과 같은 수준의 시퀀스로 나타낼 수 있습니다.

가장 낮은 수준에는 물리적 파일(데이터베이스 물리적 메모리)에 저장된 데이터가 있습니다. 최상위 수준에서 동일한 물리적 데이터에 대한 고유한 표현이 있는 응용 프로그램입니다. 각 데이터베이스 보기는 기본 물리적 데이터에서 구축된 특정 논리적 구조입니다. 사이의 인터페이스를 제공하기 위해 물리적 메모리데이터베이스 및 다양한 논리적 버전(많은 지원 보기) DBMS는 차례로 여러 수준으로 구성되어야 합니다.

2. 3단계 데이터베이스 아키텍처.

데이터의 논리적 표현과 물리적 표현의 구분은 위원회가 1978년에 공식적으로 인정했습니다. ANSI/스팍 데이터베이스 시스템의 일반화된 구조를 제안했습니다. 이러한 구조를 3계층 아키텍처라고 합니다. 아키텍처의 세 가지 수준은 내부, 개념 및 외부입니다.

내부 수준 - 물리적 저장소에 가장 가까운 데이터베이스의 물리적인 모습을 정의하는 수준으로 물리적 저장장치에 정보를 저장하는 방식과 관련이 있다. 드라이브, 물리적 주소, 인덱스, 포인터 등이 이 레벨과 연관됩니다. 이 계층은 데이터를 저장할 물리적 장치, 데이터 검색 및 업데이트에 사용할 액세스 방법, 데이터베이스 관리 속도를 유지하거나 개선하기 위해 취해야 할 조치를 결정하는 물리적 데이터베이스 설계자의 책임입니다. 체계. 사용자는 이 수준을 건드리지 않습니다.

개념적 수준 – 데이터베이스의 논리적 스키마를 정의하는 구조적 수준. 이 수준에서는 사용자의 정보 요구 분석 및 필요한 데이터 요소의 정의를 포함하는 데이터베이스의 개념 설계가 수행됩니다. 개념 설계의 결과는 개념 스키마, 모든 데이터 요소 및 이들 간의 관계에 대한 논리적 설명입니다.

외부 레벨 – 사용자 데이터 표현을 정의하는 데이터베이스의 구조적 수준. 각 사용자 그룹은 데이터베이스에 있는 데이터의 고유한 표현을 얻습니다. 이러한 각 데이터 보기는 데이터 보기를 구성하는 데이터 요소와 이들 간의 관계에 대한 사용자 지향적인 설명을 제공합니다. 개념 스키마에서 직접 파생될 수 있습니다. 이러한 사용자 정의 데이터 표현의 총체는 외부 수준을 제공합니다.

사용자 및 애플리케이션 보기

외부 레벨

디스플레이

개념도

개념적 수준

표시하다

내부 수준

호스트 시스템

저장된 데이터

쌀. DBMS 수준

3. 데이터베이스 수명 주기.

데이터베이스 시스템을 설계, 구현 및 유지 관리하는 프로세스를 데이터베이스 수명 주기(ZhTsBD). 시스템을 만드는 절차는 시스템 수명 주기(LCS).

이해와 올바른 접근접근 방식을 기반으로 하기 때문에 LCBD에 대한 매우 중요하고 자세한 고려가 필요합니다. 데이터 기반. 데이터 항목은 수행되는 시스템 기능보다 더 안정적입니다. 올바른 데이터 구조를 생성하려면 데이터 항목 클래스와 이들 간의 관계에 대한 복잡한 분석이 필요합니다. 논리적 데이터베이스 스키마를 구축하면 나중에 이 스키마를 사용하여 기능 시스템을 원하는 수만큼 생성할 수 있습니다. 기능 중심 접근 방식은 단기간 작동하도록 설계된 임시 시스템을 만드는 데만 사용할 수 있습니다.

LCBD는 다음 단계로 구성됩니다.

1. 사전 계획 - 데이터베이스 계획, 전략적 데이터베이스 계획을 수립하는 과정에서 수행. 계획 과정에서 수집되는 정보는 다음과 같습니다.

· 어떤 응용 프로그램이 사용되며 어떤 기능을 수행하는지;

· 이러한 각 응용 프로그램과 연결된 파일은 무엇입니까?

· 어떤 새로운 응용 프로그램과 파일이 진행 중인지.

이 정보는 데이터베이스 시스템에 대한 향후 요구 사항을 결정하기 위해 응용 프로그램 정보가 사용되는 방식을 결정하는 데 도움이 됩니다.

이 단계의 정보는 일반화된 데이터 모델의 형태로 문서화됩니다.

2. 타당성 확인 . 여기에서 데이터베이스 생성 계획의 기술적, 운영적 및 경제적 타당성이 결정됩니다.

· 기술적 타당성 - 계획된 데이터베이스를 구현하는 기술이 있습니까?

· 운영 타당성 – 데이터베이스 계획을 성공적으로 구현하는 데 필요한 도구와 전문가가 있습니까?

· 경제적 타당성 – 결론을 결정할 수 있습니까? 계획된 시스템이 성과를 낼까요? 비용과 편익을 평가할 수 있습니까?

3. 요구사항의 정의 데이터베이스 대상 선택, 시스템에 대한 정보 요구 사항 및 장비 요구 사항에 대한 설명을 포함합니다. 소프트웨어. 따라서 에 이 단계데이터 수집 및 요구 사항 정의 생성 일반 정보 모델, 다음 작업으로 표현:

· 시스템의 목표는 정보 요구를 분석하여 결정됩니다. 또한 생성해야 하는 데이터베이스(분산, 전체론적)와 필요한 커뮤니케이션 도구도 반드시 나타냅니다. 출력 문서는 시스템의 목표를 설명하는 주석입니다.

· 사용자 요구 사항 정의: 일반화된 정보 형식의 문서(의견, 보고서, 설문조사, 설문지 등) 고정 시스템 기능그리고 이러한 요구 사항을 충족할 애플리케이션 시스템을 정의합니다. 데이터는 관련 문서의 형태로 제공됩니다.

· 원하는 수준의 성능 유지와 관련된 하드웨어 및 소프트웨어에 대한 일반 요구 사항 결정. (시스템의 사용자 수, 하루 입력 메시지 수, 출력 수를 알아냅니다.) 이 정보는 컴퓨터 및 DBMS 유형, 디스크 볼륨, 프린터 수를 선택하는 데 사용됩니다. 이 단계의 데이터는 대략적인 하드웨어 및 소프트웨어 구성이 포함된 보고서에 나와 있습니다.

· 초기 응용 프로그램 선택을 포함하여 시스템의 단계적 생성을 위한 계획 개발.

4. 컨셉 디자인 – 데이터베이스의 개념적 스키마 생성. 사양은 구현으로 이동하는 데 필요한 정도로 개발됩니다.

주요 출력 문서는 단일 정보 모델(또는 개념적 수준의 데이터베이스 스키마). 이 모델을 개발할 때 시스템 요구사항을 수집하고 결정하는 단계에서 결정된 시스템이 수행해야 하는 정보와 기능을 사용합니다. 이 단계에서 다음을 정의하는 것도 바람직합니다. 1) 데이터에 대한 규칙; 2) 프로세스 규칙; 3) 인터페이스에 대한 규칙.

5. 구현 개념적 모델을 기능적 데이터베이스로 바꾸는 과정. 여기에는 다음 단계가 포함됩니다.

1) 필요한 DBMS의 선택 및 획득.

2) 개념적(정보학적) 데이터베이스 모델을 논리적 및 물리적 데이터 모델로 변환:

· 정보 학적 데이터 모델을 기반으로 특정 DBMS에 대한 데이터 스키마가 구축됩니다. 필요한 경우 데이터베이스가 비정규화되어 시간이 중요한 모든 응용 프로그램에서 쿼리 처리 속도가 빨라집니다.

· 데이터 스키마에서 저장 프로시저로 구현해야 하는 응용 프로그램 프로세스를 결정합니다.

· 데이터 무결성을 보장하고 데이터 규칙을 시행하도록 설계된 제약을 구현합니다.

· 제약 조건으로 지정할 수 없는 중앙에서 정의된 모든 데이터 규칙과 데이터 무결성 규칙을 구현하기 위한 트리거를 설계하고 생성합니다.

· 인덱싱 및 클러스터링 전략 개발 모든 테이블, 클러스터 및 인덱스의 크기 조정을 수행합니다.

· 사용자 액세스 수준을 정의하고 보안 및 감사 규칙을 개발 및 구현합니다. 역할 및 별칭을 생성하여 일관된 수준의 액세스 권한으로 다중 사용자 액세스를 제공합니다.

· 원격 데이터(복제 또는 분산 데이터베이스)에 대한 원활한 액세스를 위한 데이터베이스 네트워크 토폴로지 및 메커니즘을 개발합니다.

3) 데이터베이스 데이터 구조의 정의 저장을 정의하는 데이터 사전 구축. 데이터 사전에는 액세스 권한, 데이터 보호 규칙 및 데이터 제어에 대한 정보도 포함되어 있습니다.

4) 데이터베이스 채우기.

5) 창조 응용 프로그램, 관리 제어.

6) 사용자 교육.

6. 데이터베이스 스키마의 평가 및 개선.기능적으로 충족되지 않은 요구 사항을 식별하기 위한 사용자 설문 조사가 포함됩니다. 필요에 따라 변경하고 필요에 따라 새로운 프로그램과 데이터 항목을 추가하고 확장합니다.

따라서 LCBD에는 다음이 포함됩니다.

· 해당 분야의 연구 및 관련 문서 제출(1-3).

· 정보학적 모델 구축(4).

· 구현(5).

· 성능 평가 및 데이터베이스 지원(6).

4. DBMS 아키텍처.



쌀. DBMS의 주요 구성 요소

데이터, 메타데이터 - 데이터뿐만 아니라 데이터 구조에 대한 정보도 포함합니다( 메타데이터). 관계형 DBMS에서 메타데이터에는 시스템 테이블(관계), 관계 이름, 해당 관계의 속성 이름 및 해당 속성의 데이터 유형이 포함됩니다.

종종 DBMS는 다음을 지원합니다. 지수데이터. 색인 값의 일부가 존재할 때 데이터 요소를 빠르게 찾는 데 도움이 되는 데이터 구조입니다(예: 속성 중 하나의 주어진 값을 갖는 특정 관계의 튜플을 찾는 인덱스). 인덱스는 저장된 데이터의 일부이며 인덱스에 있는 속성을 나타내는 설명은 메타데이터의 일부입니다.

메모리 관리자 - 데이터 저장 위치에서 필요한 정보를 수신하고 상위 시스템 수준의 요청에 따라 정보를 변경합니다.

단순 데이터베이스 시스템에서 메모리 관리자는 운영 체제의 파일 시스템이 될 수 있습니다. 그러나 효율성을 향상시키기 위해 DBMS는 일반적으로 직접 메모리 모니터링을 수행합니다. 메모리 관리자는 두 가지 구성 요소로 구성됩니다.

· 파일 관리자 디스크에서 파일의 위치를 ​​제어하고 버퍼 관리자(디스크의 일반적인 경우로 나눈 디스크 블록- 4000~16000바이트를 포함하는 연속 메모리 영역).

· 버퍼 관리자 메인 메모리를 관리합니다. 파일 관리자를 통해 디스크에서 데이터 블록을 수신하고 특정 블록을 저장할 주 메모리 페이지를 선택합니다. 디스크 블록을 주 메모리에 임시로 저장할 수 있지만 다른 블록에 주 메모리 페이지가 필요할 때 디스크로 해제합니다. 트랜잭션 관리자의 요청에 따라 페이지도 디스크로 반환됩니다.

"요청" 프로세서 - 요청을 처리하고 데이터 또는 메타데이터에 대한 변경을 요청합니다. 필요한 작업을 수행하는 가장 좋은 방법을 제안하고 메모리 관리자에 적절한 명령을 내립니다.

쿼리 프로세서(매니저)는 매우 짧은 시간 안에 수행할 수 있는 쿼리 또는 작업을 데이터베이스에서 만듭니다. 높은 레벨(예를 들어, 요청 형식으로 SQL ), 관계의 개별 튜플 또는 관계의 인덱스 부분과 같은 저장된 데이터에 대한 쿼리 시퀀스로 변환합니다. 종종 처리의 가장 어려운 부분 요구그의 조직, 즉 좋은 선택 쿼리 계획또는 요청에 응답하는 메모리 시스템에 대한 요청 시퀀스.

트랜잭션 관리자 - 시스템의 무결성에 대한 책임이 있으며 많은 요청의 동시 처리, 간섭 요청의 부재(추가,최소 최대 ) 및 시스템 장애 시 데이터 보호. 충돌을 피하기 위해 현재 쿼리의 영향을 받는 데이터가 무엇인지 알아야 하기 때문에 쿼리 관리자와 상호 작용하고 충돌을 피하기 위해 일부 쿼리와 작업을 지연할 수 있습니다. 데이터 보호 체계에는 일반적으로 데이터 변경 로그 파일의 저장이 포함되기 때문에 트랜잭션 관리자는 메모리 관리자와도 상호 작용합니다. 작업의 올바른 순서로 파일 등록 변경 기록이 포함되므로 시스템 오류로 인해 디스크에 도달하지 못한 변경 사항도 다시 실행할 수 있습니다.

일반적인 DBMS를 사용하면 사용자가 단일 트랜잭션에서 여러 쿼리 및/또는 변경 사항을 그룹화할 수 있습니다. 거래전체적으로 순차적으로 수행되어야 하는 작업 그룹입니다.

일반적으로 데이터베이스 시스템은 동시에 많은 트랜잭션을 지원합니다. 이러한 모든 거래의 올바른 실행은 다음을 보장합니다. 거래 관리자. 트랜잭션의 적절한 실행이 보장됩니다. -속성 (원자성, 일관성, 격리성, 내구성):

· 원자성- 모든 거래를 실행하거나 전혀 실행하지 않음(예: ATM에서 돈을 인출하고 고객의 계정으로 해당 차변을 만드는 것은 단일 원자 거래여야 하며 이러한 각 작업을 별도로 수행할 수 없음)

· 일관성 - 데이터가 가능한 모든 기대치를 충족하는 상태(예를 들어, 항공사 데이터베이스에 대한 일관성 조건은 비행기의 좌석이 2명의 승객을 위해 예약되지 않은 것입니다);

· 단열재- 두 개 이상의 트랜잭션이 병렬로 실행될 때 결과는 서로 격리되어야 합니다. 2개의 거래를 동시에 동시에 실행하면 순차적으로 수행되었다면 발생하지 않았을 결과로 이어지지 않아야 함 , 하나의 요청은 완료되어야 하고, 다른 하나는 - 아니요);

· 장수 - 트랜잭션 완료 후 시스템 오류가 발생한 경우 트랜잭션 완료 직후에 오류가 발생하더라도 결과가 손실되지 않아야 합니다.

DBMS에 대한 3가지 유형의 액세스도 고려하십시오.

1. 요청 데이터에 대한 질문은 두 가지 방법으로 생성할 수 있습니다.

ㅏ)사용하여 공통 쿼리 인터페이스(예를 들어, 관계형 DBMS는 쿼리를 허용합니다. SQL , 요청 프로세서에 전달되고 이에 대한 응답도 수신함);

b) 도움으로 응용 프로그램 인터페이스- 요청은 특수 인터페이스를 통해 전송됩니다(임의의 요청은 이 인터페이스를 통해 보낼 수 없음).

2. 수정 데이터 수정 작업입니다. 공통 인터페이스나 응용 프로그램 인터페이스를 통해 실행할 수도 있습니다.

3. 회로 수정 데이터베이스 스키마를 변경하거나 새 데이터베이스를 생성할 수 있는 권한이 있는 데이터베이스 관리자의 명령입니다.

클라이언트/서버 아키텍처. 현대 소프트웨어의 많은 변형에서 아키텍처가 구현됩니다. 클라이언트 서버: 한 프로세스(클라이언트)가 다른 프로세스(서버)에 실행 요청을 보냅니다. 일반적으로 데이터베이스는 종종 서버 프로세스와 여러 클라이언트 프로세스로 분할됩니다.

가장 단순한 클라이언트/서버 아키텍처에서 전체 DBMS는 사용자와 상호 작용하고 쿼리 또는 기타 명령을 서버에 보내는 쿼리 인터페이스를 제외하고는 서버입니다. 예를 들어, 관계형 DBMS는 종종 언어를 사용합니다. SQL 클라이언트에서 서버로의 요청을 나타냅니다. 그런 다음 데이터베이스 서버는 테이블(관계) 형식의 응답을 클라이언트에 제공합니다. 서버와 동시에 작업하는 데이터베이스 사용자가 많을 경우 문제가 발생할 수 있으므로 클라이언트의 부하를 증가시키는 경향이 있다.

5. 관계형 데이터 모델.

특정 주제 영역의 RDM은 시간이 지남에 따라 변하는 관계의 집합입니다. 정보 시스템을 만들 때 일련의 관계를 통해 주제 영역의 개체에 대한 데이터를 저장하고 개체 간의 관계를 모델링할 수 있습니다.

태도 일부 데이터를 포함하는 2차원 테이블입니다. 수학적으로 아래N -이리 관계 아르 자형 데카르트 곱의 집합 이해 D 1 D 2 … D n 세트( 도메인) D 1, D 2 , … , D n (), 선택적으로 다름:

R D 1 D 2 … D n ,

여기서 D 1 D 2 … D n 완전한 데카르트 곱, 즉 다양한 조합의 N 각 요소는 자체 도메인에서 가져온 것입니다.

도메인 의미론적 개념이다. 도메인은 특정 의미를 갖는 일부 데이터 유형 값의 하위 집합으로 생각할 수 있습니다. 도메인의 특징은 다음과 같습니다.

· 도메인이 독특한 이름(데이터베이스 내에서).

· 도메인은 일부에 정의되어 있습니다. 단순한데이터 유형 또는 다른 도메인에 있습니다.

· 도메인에 일부가 있을 수 있습니다. 부울 조건이 도메인에 유효한 데이터의 하위 집합을 설명할 수 있는 A입니다.

· 도메인은 특정 의미적 부하.

관계 속성 몇 가지 유형이 있습니다<Имя_атрибута: Имя_домена>. 속성 이름은 관계 내에서 고유해야 합니다. 종종 관계의 속성 이름은 해당 도메인의 이름과 동일합니다.

비율 여러 도메인에 정의된 에는 헤더와 본문의 두 부분이 포함됩니다.

관계 헤더 고정된 수의 관계 속성입니다.

관계의 표제는 관계가 정의된 도메인의 데카르트 곱을 설명합니다. 헤더는 정적이며 데이터베이스로 작업하는 동안 변경되지 않습니다. 속성이 관련하여 변경, 추가 또는 제거된 경우 결과적으로 이미 다른관계(동일한 이름이더라도).

관계 본문 많이 포함 튜플 처지. 각 관계 튜플 형식의 쌍의 집합입니다.<Имя_атрибута: Значение_атрибута>:

속성 값이 도메인에 속하도록 합니다. 관계 본문은 튜플의 집합입니다. 도메인의 데카르트 곱의 하위 집합입니다. 따라서 관계의 본문은 실제로 단어의 수학적 의미에서 관계입니다. 관계 본문은 데이터베이스로 작업하는 동안 변경될 수 있습니다. 튜플은 변경, 추가 및 제거될 수 있습니다.

관계는 일반적으로 다음과 같이 작성됩니다.

또는 더 짧은

,

또는 단순히

관계의 속성 수를 호출합니다. (또는 -의리 ) 관계. 관계에서 튜플 집합의 카디널리티를 호출합니다. 처지.

관계 체계 이 관계의 속성 이름 목록이 호출되어 해당 속성이 속한 도메인을 나타냅니다.

속성이 동일한 도메인에서 값을 취하는 경우 -comparable이라고 합니다. 여기서 주어진 도메인에 대해 지정된 유효한 비교 작업 세트입니다. 예를 들어 도메인에 숫자 데이터가 포함된 경우 모든 비교 작업이 허용되며 . 그러나 문자 데이터가 포함된 도메인의 경우 값의 같음 및 부등식에 대한 비교 연산뿐만 아니라 지정할 수 있습니다. 주어진 도메인에 사전식 순서가 지정되면 전체 범위의 비교 작업도 수행됩니다.

두 관계의 계획을 호출합니다. 동등한 , 동일한 정도를 갖고 스키마에서 속성 이름을 정렬하여 비교할 수 있는 속성이 같은 위치에 있도록 할 수 있는 경우, 즉 동일한 도메인에서 값을 취하는 속성:

허락하다 - 관계 다이어그램. – 속성 이름 순서 지정 후 관계 체계. 그 다음에

~

따라서 등가 관계에 대해 다음 조건이 충족됩니다.

· 테이블에는 동일한 수의 열이 있습니다.

· 테이블에는 동일한 제목의 열이 있습니다.

· 동일한 이름을 가진 열에는 동일한 도메인의 데이터가 포함됩니다.

· 테이블의 행은 동일하지만 열의 순서가 다를 수 있습니다.

이러한 테이블은 모두 다릅니다. 이미지같은 관계.

관계 속성. 관계의 속성은 위의 관계 정의에서 직접 따릅니다. 이러한 속성은 관계와 테이블 간의 주요 차이점입니다.

· 관계에 동일한 튜플이 없습니다. .

· 튜플은 순서가 지정되지 않습니다(위에서 아래로). .

· 속성이 정렬되지 않음(왼쪽에서 오른쪽으로) .

· 모든 속성 값은 원자적입니다. .

쌀. 관계의 도식적 표현

관계형 모델 일련의 상호 연결된 관계 형태의 데이터베이스입니다. 각 연결에서 하나의 관계는 주 관계로 작동할 수 있고 다른 관계는 종속 관계로 작동할 수 있습니다. 따라서 주 관계의 하나의 튜플은 종속 관계의 여러 튜플과 연관될 수 있습니다. 이러한 관계를 지원하려면 두 관계 모두 관련 속성 집합을 포함해야 합니다. 기본적으로 이 관계 기본 키 , 기본 관계의 튜플을 고유하게 식별합니다. 자식 관계는 관계를 모델링하기 위해 부모 관계의 기본 키에 해당하는 속성 집합을 가져야 합니다. 그러나 여기에서 이 속성 집합은 이미 보조 키 또는 외래 키 , 즉. 단일 주요 관계 튜플과 연결된 관계 튜플 세트를 정의합니다.

6. 관계형 데이터베이스 설계.

관계형 데이터베이스를 설계할 때 다음과 같은 문제를 해결해야 합니다.

1) 주제 영역의 의미를 고려하여 주제 영역의 객체를 추상적인 데이터 모델(데이터 논리 설계)의 형태로 가장 잘 표현하는 것이 필요합니다. 저것들. - 데이터베이스 스키마 결정: 데이터베이스는 어떤 관계로 구성되어야 하는지, 이러한 관계에는 어떤 속성이 있어야 하는지, 관계 간의 관계는 무엇인지 결정합니다.

2) 데이터베이스 쿼리 실행의 효율성을 보장합니다(데이터베이스 물리적 설계).

데이터 논리적 설계 단계 후에 다음과 같은 결과 문서를 얻어야 합니다.

· 관계형 데이터 모델을 기반으로 올바른 데이터 스키마를 구축합니다.

· 선택한 DBMS 측면에서 데이터베이스 스키마에 대한 설명입니다.

· 설명 외부 모델선택한 DBMS 측면에서.

· 데이터베이스 무결성을 유지하기 위한 선언적 규칙에 대한 설명입니다.

· 데이터베이스의 의미론적 무결성을 유지하기 위한 절차 개발.

따라서 관계형 데이터베이스를 설계하는 작업은 다양한 대체 옵션에서 데이터베이스 스키마를 선택하는 것입니다.

옳은 관계 속성 간에 원치 않는 종속성이 없는 데이터베이스 스키마라고 합니다. 올바른 데이터베이스 스키마를 개발하는 프로세스를 논리적인 디자인 .

데이터베이스 스키마 디자인은 두 가지 방법으로 수행할 수 있습니다.

· 분해(파티셔닝) 방식 데이터베이스 스키마에 포함된 원래 관계 세트는 원래 관계의 투영인 다른 관계 세트로 대체됩니다! 동시에 관계의 수도 증가합니다.

· 합성 방법 주제 영역의 객체 사이에 주어진 초기 기본 종속성에서 데이터베이스 스키마를 연결합니다.

고전 데이터베이스 설계는 이론과 관련이 있습니다. 표준화 , 이는 관계 속성 간의 기능적 종속성 분석을 기반으로 합니다. 기능적 종속성은 고려 중인 주제 영역에서 개체와 속성 간의 안정적인 관계를 정의합니다.

분해 방법은 관계 체계의 연속적인 정규화 과정입니다. 각각의 새로운 반복은 고차 정규 형식에 해당하고 이전 것보다 더 나은 속성을 갖습니다. 따라서 데이터베이스의 모든 속성을 포함하는 보편적인 관계의 존재가 초기에 가정됩니다. 더 작은 차원의 여러 관계로 전환하고 자연 조인 작업을 사용하여 원래 관계를 복원해야 합니다.

따라서 각 정규형은 특정 제약 조건 집합에 해당하고 관계는 자체 제약 집합을 충족하는 경우 정규 형식입니다.

관계형 데이터베이스 이론에서 일반적으로 다음과 같은 정규형이 구별됩니다.

첫 번째 정규형(1 NF);

· 제2정규형(2 NF);

· 제3정규형(3 NF);

· Bayes-Codd 정규형( BCNF);

· 제4정규형(4 NF);

· 다섯 번째 정규형 또는 투영형 - 연결(5 NF 또는 PYNF).

일반 형태의 주요 속성:

· 각각의 연속적인 정규형은 이전의 것보다 어떤 의미에서는 더 좋습니다.

· 다음 일반 형식으로 전달할 때 이전 일반 속성의 속성이 유지됩니다.

데이터베이스 스키마는 동등한, 결과 스키마에 포함된 관계의 자연스러운 연결에 의해 원본 데이터베이스의 내용을 얻을 수 있고 원본 데이터베이스에 새 튜플이 표시되지 않는 경우.

7. 관계의 정상적인 형태.

정규화 프로세스는 모델링된 객체에 대한 데이터를 포함하는 테이블 형태의 주제 영역과 시간이 지남에 따라 데이터베이스 상태를 변경할 가능성을 기반으로 합니다. 일반적으로 도메인 데이터 모델의 불일치로 인해 해당 작업을 수행할 때 나타나는 이상이 발생할 수 있습니다.

· 예외 삽입(INSERT) - 한 면에서 이기종 정보의 저장.

· 이상 업데이트(UPDATE) – 이기종 스토리지로 인한 관계 데이터의 중복성.

· 삭제 이상(DELETE) - 한 면에서 이기종 정보의 저장.

에 대해서도 고려해야 한다. 한정되지 않은 ( 없는) 값. 서로 다른 DBMS에서 다양한 연산(비교, 합집합, 정렬, 그룹화 등)을 수행할 때 두 가지없는 -값은 서로 같을 수도 있고 같지 않을 수도 있으며, 평균값을 결정하고 값의 수를 찾는 작업을 수행한 결과에 다르게 영향을 미칩니다. 많은 DBMS에서 오류를 제거하기 위해없는 - 계산을 수행할 때 값 0, 모두 선언없는 -서로 동일한 값 등

표준화 - 테이블을 여러 개로 분할하여 데이터를 업데이트, 삽입 및 삭제할 때 더 나은 속성을 갖습니다. 저것들. 정규화는 테이블이 모두 5NF가 될 때까지 전체 분해로 테이블을 연속적으로 교체하는 프로세스이지만 실제로는 테이블을 BCNF로 줄이는 것으로 충분합니다.

정규화 절차는 모든 테이블의 유일한 기능적 종속성은 형식의 종속성이어야 한다는 사실을 기반으로 합니다. 여기서 는 기본 키이고 는 다른 필드입니다. 따라서 정규화 과정에서 모든 "기타" 기능 종속성을 제거해야 합니다. 와 다른 외모를 가진 것들로부터.

기본(외부) 키의 코드를 정규화 시간으로 바꾸면 다음 두 가지 경우를 고려해야 합니다.

1. 테이블에는 예를 들어 복합 기본 키와 기능적으로 이 키의 일부(예: 전체 키에 종속되지 않음)에 종속되는 필드가 있습니다. 및 ( - 기본 키)를 포함하는 다른 테이블을 구성하고 원래 테이블에서 삭제하는 것이 좋습니다.

교체 , 기본 키 , FZ

에 , 기본 키

및 , 기본 키 .

2. 테이블에는 기본(가능한) 키, 가능한 키가 아니지만 기능적으로 에 의존하는 필드 및 기능적으로 다음에 의존하는 키가 아닌 다른 필드가 있습니다. ( - 기본 키) 및 - 원본 테이블에서 삭제를 모두 포함하는 테이블을 구성하는 것이 좋습니다.이러한 작업을 수행하려면 처음에 입력으로 "큰"(보편적인) 관계가 있어야 합니다.

Def.1. 관계는 첫 번째 정규형(1NF) 해당 행이 해당 필드에 단일 값을 포함하지 않고 관계의 키 필드가 비어 있지 않은 경우에만 해당됩니다.

정의 1에 따르면 모든 관계는 1NF에 있습니다. 관계의 속성을 충족하는 관계: 관계에 동일한 튜플이 없습니다. 튜플은 순서가 지정되지 않습니다. 속성은 순서가 지정되지 않고 이름이 다릅니다. 모든 속성 값은 원자적입니다.

정의2. 관계는 제2정규형(2NF) 관계가 1NF에 있고 해당 부분에 의존하는 키가 아닌 속성이 없는 경우에만 복잡한 키(즉, 기본 키에 포함되지 않은 모든 필드는 기본 키와의 완전한 기능 종속성과 연관됩니다).

후보 키가 단순하면 관계는 자동으로 2NF입니다.

복잡한 키의 일부에 대한 속성의 종속성을 제거하려면 다음이 필요합니다. 분해 여러 관계로의 관계. 복잡한 키의 일부에 의존하는 속성은 별도의 관계에서 제거됩니다.

관계의 속성을 호출 상호 독립 둘 다 기능적으로 서로 의존하지 않는 경우.

Def.3. 관계는 제3정규형(3NF) 관계가 2NF에 있고 키가 아닌 모든 속성이 상호 독립적인 경우에만(즉, 관계의 키가 아닌 필드가 다른 키가 아닌 필드에 기능적으로 종속되지 않음).

키가 아닌 속성의 종속성을 제거하려면 관계를 여러 관계로 분해해야 합니다. 이 경우 종속된 키가 아닌 속성은 별도의 관계에서 제거됩니다.

정규화 알고리즘을 사용하여 관계를 3NF의 관계로 축소할 때 모든 관계가 하나의 후보 키를 포함한다고 가정합니다. 이것은 항상 사실이 아닙니다. 관계에 여러 키가 포함될 수 있는 경우가 있습니다.

Def.4. 관계는 Bays-Codd 정규형 (NFBK)모든 기능적 종속성의 결정자가 잠재적 키인 경우에만(또는 - 창 사이의 기능적 종속성이 가능한 키에 대한 완전한 기능적 종속성으로 축소되는 경우).

관계가 BCNF에 있으면 정의 4에 따라 자동으로 3NF에 있습니다. 잠재적 키가 아닌 결정자에 대한 종속성을 제거하려면 이러한 결정자와 종속 부분을 별도의 관계로 가져와 분해해야 합니다.

관계에 기능적 종속성이 없는 경우가 있습니다. 저것들. 관계가 완전히 핵심입니다. 관계의 핵심은 속성의 전체 집합입니다. 따라서 우리는 다중값 종속성, 왜냐하면 속성 사이에는 여전히 관계가 있습니다.

Def.5. 관계는 제4정규형(4NF) 관계가 BCNF에 있고 중요하지 않은 다중값 종속성을 포함하지 않는 경우에만 해당됩니다.

사소하지 않은 다중 값 종속성을 가진 관계는 일반적으로 어떤 관계에서도 핵심이 아닌 공통 필드를 따라 두 관계의 자연스러운 연결의 결과로 발생합니다. 실제로 이것은 하나의 관계에서 두 개의 독립적인 엔터티에 대한 정보를 저장하게 됩니다.

중요하지 않은 다중값 종속성을 제거하기 위해 원래 관계를 여러 개의 새로운 관계로 분해할 수 있습니다.

Def.6. 관계는 제5정규형(5NF) 존재하는 연결 종속성이 사소한 경우에만.

Def.6. 마찬가지로 정의를 따릅니다.

Def.7. 관계가 다음과 같으면 관계는 5NF에 속하지 않습니다. 사소한 의존성사이.

저것. 각 전체 분해에서 원래 관계의 모든 투영에 가능한 키가 포함되어 있으면 관계가 5NF에 있다는 결론을 내릴 수 있습니다. 완전한 분해가 없는 관계도 5NF에 있습니다.

관계에 어떤 잠재적 키가 있고 속성이 어떻게 관련되어 있는지 알지 못하면 관계가 5NF 또는 기타 일반 형식이라고 말할 수 없습니다.

가능한 키 관계는 완전하고 모호하지 않게(기능적으로 완전한) 다른 모든 관계 속성의 값을 결정하는 관계 속성의 집합입니다. 일반적으로 관계에는 몇 가지 가능한 키가 있을 수 있습니다. 관계의 가능한 모든 키 중에서 원칙적으로 하나가 선택되며, 이는 주요 것으로 간주되고 관계의 기본 키라고 합니다.

상호 독립 속성 이들은 서로 의존하지 않는 속성입니다. 관계에 여러 FD가 있는 경우 다른 속성이 의존하는 각 속성 또는 속성 집합을 관계의 결정자(determinant)라고 합니다.

9. 관계 대수학.

관계형 대수는 관계형 데이터에 액세스하기 위한 기초입니다. 대수학의 주요 목적은 식을 작성하는 방법을 제공하는 것입니다. 표현식을 사용하여 다음을 수행할 수 있습니다.

· 영역 정의 샘플, 즉. 페치 동작의 결과로서 선택을 위한 데이터를 정의하는 단계;

· 영역 정의 업데이트, 즉. 업데이트 작업의 결과로 삽입, 수정 또는 삭제될 데이터를 결정하는 단계;

· 정의 (명명) 가상 관계, 즉. 보기를 통한 시각화를 위한 데이터 표시

· 스냅샷 정의, 즉 관계의 "스냅샷"으로 저장할 데이터를 결정하는 단계;

· 보안 규칙 정의, 즉 액세스 제어가 수행되는 데이터를 결정하는 단계;

· 지속 가능성 요구 사항의 결정, 즉. 일부 동시성 제어 작업을 위한 영역에 포함된 데이터를 결정하는 단계;

· 무결성 규칙의 정의, 즉. 데이터베이스가 충족해야 하는 몇 가지 특수 규칙과 함께 일반적인 규칙, 관계형 모델의 일부를 나타내며 각 데이터베이스에 적용됩니다.

특정 관계형 DBMS의 구현에서는 현재 관계 대수나 관계 미적분을 순수한 형태로 사용하지 않습니다. 관계형 데이터에 액세스하기 위한 사실상의 표준이 되었습니다. SQL 언어(구조적 쿼리 언어).

Codd가 정의한 관계 대수는 2개의 그룹을 구성하는 8개의 연산자로 구성됩니다.

  • 전통적인 집합 연산 (합집합, 교차, 빼기, 데카르트 곱);
  • 특수 관계 연산 (선택, 투영, 연결, 분할).

또한 대수에는 대수식 계산 결과를 데이터베이스에 저장할 수 있는 할당 작업과 결과 관계의 제목(도표)을 올바르게 구성할 수 있는 속성 이름 변경 작업이 포함됩니다.

관계 대수 연산자에 대한 간략한 조사.

견본일부 조건을 충족하는 특정 관계의 모든 튜플을 포함하는 관계를 반환합니다. 선택 작업은 제한 작업(얽매다 - 제한, 샘플링이 더 자주 허용됨 -고르다 ).

투사일부 속성을 제외하고 특정 관계의 모든 튜플(즉, 하위 튜플)을 포함하는 관계를 반환합니다.

일하다정의된 두 관계에 각각 속하는 두 튜플의 조합인 가능한 모든 튜플을 포함하는 관계를 반환합니다.

협회지정된 두 관계 중 하나 또는 둘 다에 속하는 모든 튜플을 포함하는 관계를 반환합니다.

교차로 -정의된 두 관계에 동시에 속하는 모든 튜플을 포함하는 관계를 반환합니다.

빼기 -정의된 두 관계 중 첫 번째 관계에 속하고 두 번째 관계에는 속하지 않는 모든 튜플을 포함하는 관계를 반환합니다.

연결(내츄럴) – 튜플이 이 두 관계의 하나 이상의 공통 속성에 대한 공통 값을 갖는 두 개의 튜플(각각 두 개의 특정 관계에 속함)의 조합인 관계를 반환합니다(그리고 이러한 공통 값은 결과 튜플에서 한 번만 나타납니다. 두번 아님).

분할 -이진 및 단항의 두 관계에 대해 단항 관계의 모든 값(다른 속성에서)과 일치하는 이진 관계의 한 속성의 모든 값을 포함하는 관계를 반환합니다.

문학

1. 날짜 K.J. 데이터베이스 시스템 소개, 6판: Per. 영어로부터. - 에게.; 중.; 상트페테르부르크: Williams Publishing House, 2000. - 848 p.

2. Connolly T., Begg K., Strachan A. 데이터베이스: 설계, 구현 및 유지 관리. 이론과 실습, 2nd ed.: Per. 영어로부터. – M.: Williams Publishing House, 2000. – 1120 p.

3. 카르포바 T.S. 데이터베이스: 모델, 개발, 구현. - 상트페테르부르크: Peter, 2001. - 304 p.

4. Faronov V.V., Shumakov P.V. 델파이 4. 데이터베이스 개발자 가이드. - M .: "지식", 1999. - 560 p.

5. J. 그로프, P. 와인버그. SQL: 완전한 가이드: 당. 영어로부터. - K .: BHV 출판 그룹, 2001. - 816 p.

6. 켄 게츠, 폴 리트빈, 마이크 길버트. 2000 개발자 안내서에 액세스하십시오. T.1, 2. 당. 영어로부터. - K .: BHV Publishing Group, 2000. - 1264 p., 912 p.

7. Maklakov S.V. BPwin 및 EPwin. 정보 시스템 개발을 위한 CASE 도구. - M.: DIALOG-MEPHI, 2001. - 304 p.

8. Ulman D., Widom D. 데이터베이스 시스템 소개 / Per. 영어로부터. - M .: "Lori", 2000. - 374 p.

9. Homonenko A.D., Tsygankov VM, Maltsev M.G. 데이터베이스: 고등 교육 기관을 위한 교과서 / Ed. 교수 A.D. 호모넨코 - St. Petersburg: CROWN print, 2000. - 416 p.

7.2. IDEF1X 방법론을 사용한 개념 설계

개념 설계의 목적 – 각 개별 사용자 유형의 주제 영역 개념을 기반으로 개념적 데이터 스키마 생성. 개념도 허용된 데이터베이스 모델과 대상 DBMS의 구문을 고려하지 않은 주요 엔터티(테이블) 및 이들 간의 관계에 대한 설명입니다. 종종 이러한 체계는 속성을 지정하지 않고 엔터티(테이블)의 이름만 표시합니다. 사용자 보기 특정 사용자가 결정을 내리거나 일부 작업을 수행하는 데 필요한 데이터가 포함됩니다.

[ , ]의 개념 설계 단계 순서는 아래에 설명되어 있습니다.

1. 법인의 선정.

개념적 데이터 스키마를 구축하는 첫 번째 단계는 사용자가 관심을 가질 수 있으므로 데이터베이스에 저장해야 하는 주요 개체(엔티티)를 식별하는 것입니다. 기능적 모델이 있는 경우 이러한 객체의 프로토타입은 입력, 제어 및 출력입니다. 이러한 목적으로 사용하는 것이 더욱 좋습니다. 이 경우 객체의 프로토타입은 데이터 저장 장치가 됩니다. 위에서 언급했듯이 데이터 저장소는 테이블 모음(객체 집합)이거나 직접 테이블(객체)입니다. 주요 객체 집합에 대한 보다 자세한 정의를 위해서는 데이터 흐름과 전체 체계적인 자료문제를 해결하는 데 필요합니다. 예를 들어, 허용 속도를 결정하는 작업의 경우 주요 개체(물체 세트)는 규제 및 참조 정보, 도로 섹션에 대한 정보, 계산 작업, 허용 속도 목록 등입니다. 정보 모델을 분석하고 설계하는 동안 개체 집합을 자세히 설명해야 합니다. 예를 들어, 해결되는 문제의 세부 사항을 고려하여 "도로 섹션에 대한 정보"라는 복합 객체는 섹션, 트랙, 별도의 포인트, 마일리지, 계획, 트랙의 상부 구조 등 별도의 구성 요소로 분할해야 합니다.

개체 식별의 가능한 어려움은 작업 관리자 사용과 관련이 있습니다.

개체를 설명할 때의 예 및 유추(예: "직원"의 일반화 개념 대신 "머리", "책임", "관리자", "대리인"과 같은 기능 또는 위치를 언급할 수 있음)

동의어(예: "허용 속도" 및 "속도 설정", "개발" 및 "프로젝트", "배리어 사이트" 및 "속도 제한")

동음이의어(예: "프로그램"은 다음을 의미할 수 있습니다. 컴퓨터 프로그램, 작업 계획 또는 TV 가이드).

엔티티, 관계 또는 속성과 같은 특정 개체가 무엇인지 항상 명확하지 않습니다. 예를 들어, "가족 결혼"은 어떻게 분류되어야 합니까? 실제로 이 개념은 위의 범주 중 하나에 상당히 합리적으로 귀속될 수 있습니다. 분석은 주관적인 과정이므로 다른 개발자는 동일한 사실에 대해 다르지만 상당히 유효한 해석을 만들 수 있습니다. 옵션의 선택은 크게 디자이너의 상식과 경험에 달려 있습니다.

각 엔터티에는 몇 가지 속성이 있어야 합니다.

고유한 이름이 있어야 하며 항상 동일한 이름에 동일한 해석이 적용되어야 합니다.

엔티티가 소유하거나 관계를 통해 상속되는 하나 이상의 속성이 있습니다.

엔티티의 각 인스턴스를 고유하게 식별하는 하나 이상의 속성(기본 키)을 갖습니다. 즉, 테이블의 각 행을 고유하게 만듭니다.

다른 엔터티와 관계를 얼마든지 가질 수 있습니다.

IDEF1X 그래픽 표기법은 다음 그림과 같은 표기법을 사용하여 엔터티를 표시합니다.

a) 독립 b) 종속

쌀. 7.1. 에센스

IDEF1X 방법론의 엔티티는 독립적인 (강한, 부모의, 지배적인, 소유자) , 엔티티가 다른 엔티티의 존재에 의존하지 않는 경우(즉, 엔티티의 각 인스턴스는 다른 엔티티와의 관계를 정의하지 않고 고유하게 식별될 수 있거나 인스턴스의 고유성이 자체 속성에 의해서만 결정됨). 엔티티가 호출됩니다 종속 (약한, 자식, 종속) 그 존재가 다른 엔티티의 존재에 의존하는 경우. "부모" - "자식" 및 "소유자" - "하위"라는 용어는 두 종속 엔터티와 관련하여 사용할 수도 있습니다. , 소유자), 두 번째 엔터티가 차례로 세 번째 엔터티에 종속됨에도 불구하고.

2. 속성의 정의.

일반적으로 속성은 엔터티에 대해서만 지정됩니다. 관계에 속성이 있으면 관계가 엔터티임을 나타냅니다. 속성을 정의하는 가장 쉬운 방법은 엔터티 또는 관계를 식별한 후 "...에 대해 어떤 정보를 저장하시겠습니까?"라는 질문을 스스로에게 하는 것입니다. 속성을 결정하는 데 크게 도움이 될 수 있는 다양한 종이 및 전자 양식 및 문서는 조직에서 문제를 해결하는 데 사용됩니다. 이는 초기 정보(예: "곡선의 외부 레일 고도 목록")와 데이터 처리 결과(예: "양식 번호 1")를 모두 포함하는 양식일 수 있습니다.

식별된 속성은 다음 유형일 수 있습니다.

단순(원자, 분할 불가) - 독립적으로 존재하는 하나의 구성 요소로 구성됩니다(예: "직원 위치", "급여", "뛰어난 가속도", "곡선 반경" 등).

복합(의사 원자) - 여러 구성 요소(예: "이름", "주소" 등)로 구성됩니다. 모델에 포함된 속성의 원자성 정도는 개발자가 결정합니다. 시스템이 Ivanov 성을 가진 모든 클라이언트를 선택하거나 Komsomolskaya Street에 거주하는 모든 클라이언트를 선택하지 않아도 되는 경우 복합 속성을 원자 속성으로 나눌 수 없습니다.

모호하지 않음 - 엔티티의 한 인스턴스에 대해 하나의 값만 포함합니다(예: 평면의 곡선은 반지름, 회전 각도, 외부 레일의 고도 등에 대해 하나의 값만 가질 수 있음).

다중값 - 여러 값을 포함합니다(예: 회사의 한 지점에 여러 연락처 번호가 있을 수 있음).

파생(계산) - 속성의 값은 다른 속성의 값에서 결정할 수 있습니다(예: "나이"는 "생년월일"과 컴퓨터에 설정된 현재 날짜에서 결정할 수 있음).

키 - 엔티티 인스턴스(기본 키의 일부)를 고유하게 식별하는 역할을 합니다. 빠른 탐색엔티티의 인스턴스 또는 상위 엔티티와 하위 엔티티의 인스턴스 간의 관계 설정,

키가 아닌(설명적);

필수 - 엔티티에 새 인스턴스를 입력하거나 편집할 때 유효한 속성 값을 지정해야 합니다. 지정된 조치 후에는 정의되지 않을 수 있습니다(NULL이 아님). 엔터티의 기본 키에 포함된 속성은 필수입니다.

속성이 정의된 후 설정됩니다. 도메인(허용되는 값의 영역) , 예를 들어:

사이트 이름 - 길이가 60자 이하인 러시아 알파벳 문자 세트.

곡선 회전 - 유효한 값 "L"(왼쪽) 및 "R"(오른쪽);

곡선의 반경은 4자리 이하의 양수입니다.

도메인을 지정하면 속성(여러 속성)의 유효한 값 집합과 속성의 유형, 크기 및 형식이 정의됩니다.

엔티티에 대해 선택된 속성 세트를 기반으로 키 세트가 결정됩니다. 열쇠 – 인스턴스, 빠른 검색을 고유하게 식별하거나 상위 엔티티와 하위 엔티티 인스턴스 간의 관계를 설정하는 역할을 하는 엔티티의 하나 이상의 속성. 인스턴스를 고유하게 식별하는 데 사용되는 키는 다음 유형에 속합니다.

- 슈퍼 키 – 개체의 인스턴스를 고유하게 식별하는 속성 또는 속성 집합. 수퍼키는 인스턴스를 고유하게 식별하는 데 필요하지 않은 "추가" 속성을 포함할 수 있습니다. 데이터베이스 구조의 올바른 디자인으로 각 엔터티(테이블)의 슈퍼키는 해당 속성의 전체 집합이 됩니다.

- 잠재적 키 - 이 개체의 슈퍼키이기도 한 부분집합을 포함하지 않는 슈퍼키, 즉 개체 인스턴스를 고유하게 식별하는 최소한의 필수 속성 집합을 포함하는 슈퍼키. 엔터티는 여러 후보 키를 가질 수 있습니다. 키가 여러 속성으로 구성된 경우 복합 키라고 합니다. 인스턴스의 고유한 식별을 위한 전체 잠재적 키 세트 중에서 하나가 선택되는데, 소위 기본 키라고 하며, 이는 나중에 다른 엔터티와의 관계를 설정하는 데 사용됩니다.

- 기본 키 - 엔터티 내에서 인스턴스를 고유하게 식별하기 위해 선택된 후보 키

- 대체 키 – 기본 키로 선택되지 않은 후보 키.

예를 들어 보십시오. 다음 열이 있는 학생 정보가 포함된 테이블이 있다고 가정합니다.

성;

중간 이름;

생일;

출생지;

그룹 번호;

연금 보험 증명서(NPSS) 번호

여권 아이디;

여권 발급일

여권을 발급한 기관입니다.

각 인스턴스(레코드)에 대해 전체 속성 집합을 슈퍼키로 선택할 수 있습니다. 잠재적 키(고유 식별자)는 다음과 같을 수 있습니다.

연금보험증의 번호

여권 아이디.

고유 식별자로 "성" + "이름" + "패트로니믹" 속성 세트를 선택하는 것이 가능합니다. 만약 두 명의 정식 이름이 같은 대학에서 공부할 확률이 0일 경우입니다.

엔터티에 잠재적 키의 역할에 적합한 속성 조합이 없으면 별도의 속성이 엔터티에 추가됩니다. 대리 키(인공 키, 대리 키) . 일반적으로 이러한 속성의 유형은 문자 또는 숫자로 선택됩니다. 일부 DBMS에는 대리 키 값을 생성하고 유지하기 위한 도구가 내장되어 있습니다(예: MS Access). 일부 개발자는 잠재적인 키를 검색하고 그 중에서 기본 키를 선택하는 대신 나중에 기본 키로 사용되는 각 엔터티에 인위적인 속성을 추가한다는 점도 주목할 가치가 있습니다.

잠재적인 키가 여러 개인 경우 다음 규칙에 따라 기본 키를 선택하는 것이 좋습니다.

키에 포함된 속성의 수는 최소이어야 합니다(키는 원자성, 즉 하나의 속성으로 구성되는 것이 바람직함).

바이트 단위의 키 크기는 가능한 한 짧아야 합니다.

키 도메인 유형은 숫자입니다. 키에서 문자 속성을 선택할 때 종종 잘못된 값을 입력하는 데 문제가 있습니다(대소문자 혼동, 공백 추가, 다른 언어에서 철자가 동일한 문자 사용). 숫자 속성은 값을 입력할 때 오류가 발생할 가능성이 적습니다.

키 값을 변경할 확률이 가장 작았습니다(예: "연금 보험 증명서 번호"는 "TIN" 또는 "여권 번호"보다 더 일정한 매개변수임).

키는 사용자가 작업하기 가장 쉽습니다(예: "연금 보험 증명서 번호"는 11자리 숫자이며 "여권 번호"는 유형에 따라 다릅니다: 소련 시민, 러시아 연방 시민 또는 외국).

특정 속성(속성 집합)이 여러 엔터티에 있는 경우 해당 존재는 일반적으로 이러한 엔터티 인스턴스 간의 관계 존재를 반영합니다. 각 관계에서 한 엔터티는 부모 역할을 하고 다른 엔터티는 자식 역할을 합니다. 이는 부모 엔터티의 한 인스턴스가 자식의 여러 인스턴스와 연결될 수 있음을 의미합니다. 이러한 관계를 지원하려면 두 엔터티가 관련된 속성 집합을 포함해야 합니다. 상위 엔터티에서 이것은 기본 키입니다. 관계를 모델링할 자식 엔터티에는 부모의 기본 키에 해당하는 속성 집합이 있어야 합니다. 자식 엔터티의 이 속성 집합을 외래 키 .

IDEF1X 표기법에서 속성은 엔티티 블록 내의 이름 목록으로 표시됩니다. 기본 키를 정의하는 속성은 목록의 맨 위에 배치되고 가로 막대로 다른 속성과 구분됩니다. 두 엔터티의 예에서 속성의 예비 식별은 다음 그림에 나와 있습니다.

쌀. 7.2. 엔티티 예시

독립 엔터티 "Plots"에는 기본 키로 대리 키가 있고 종속 엔터티 "Plan"에는 5개의 속성으로 구성된 복합 기본 키가 있습니다.

3. 연결의 정의.

엔터티 간의 가장 특징적인 관계 유형은 다음과 같습니다.

일반적으로 동사 "구성", "포함" 등으로 정의되는 "부분-전체" 유형의 링크.

관계 분류(예: "유형 - 하위 유형", "세트 - 요소", "일반 - 특정" 등)

노사 관계(예: "상사-하급")

기능적 연결은 일반적으로 "생성하다", "영향을 미치다", "에 의존한다", "~에 의해 계산된다" 등의 동사로 정의됩니다.

그 중 데이터베이스 개발 요구 사항을 충족하는 데 필요한 링크만 구별됩니다.

통신은 다음과 같은 매개변수 집합이 특징입니다.

이름 - 동사의 형태로 표시되고 연결의 의미론(의미론적 배경)을 결정합니다.

다중도(카디널리티, 전력): 일대일(1:1), 일대다(1:N) 및 다대다(N:M, N = M 또는 N<>중). 다중성은 한 엔터티의 인스턴스가 다른 인스턴스에 의해 결정되는 수를 보여줍니다. 예를 들어, 한 섹션("Parcels" 테이블의 행으로 설명됨)에는 하나, 둘 또는 그 이상의 경로가 있을 수 있습니다(각 경로는 "Paths" 테이블에서 별도의 행으로 설명됨). 에 이 경우 1:N 결합. 또 다른 예: 하나의 경로는 여러 개의 개별 지점을 통과하고 여러 경로는 하나의 개별 지점을 통과할 수 있습니다. N:M 연결.

유형: 식별(외래 키라고 하는 한 엔터티의 속성은 자식의 일부이며 해당 인스턴스를 식별하는 역할을 합니다. 즉, 기본 키에 포함됨) 및 비식별(외래 키는 자식 엔터티에 있지만 기본 키의 일부가 아님);

필수: 필수(새 인스턴스가 자식 엔터티에 입력될 때 외래 키 속성의 입력은 필수이며 입력된 값은 상위 엔터티의 일부 인스턴스의 기본 키 속성 값과 일치해야 함) 및 선택적(자식 개체의 인스턴스에서 외래 키 속성을 채우는 것은 선택 사항이거나 입력된 값이 상위 개체의 인스턴스가 없는 기본 키 속성 값과 일치하지 않음);

참여 정도는 관계에 참여하는 엔터티의 수입니다. 기본적으로 엔터티 간에는 이진 관계가 있습니다. 두 엔티티를 연결하는 협회(참여 정도는 2). 예를 들어 "사이트"는 "경로"로 구성됩니다. 동시에 참여 정도에 따라 다음과 같은 유형의 연결이 가능합니다.

o 단항(재귀) - 엔터티가 자체와 연관될 수 있습니다. 예를 들어, "직원" 테이블에는 부하 직원과 상사 모두에 대한 레코드가 있을 수 있습니다. 그런 다음 하나의 테이블에 정의된 "상사"- "하위" 관계가 가능합니다.

o 삼항 - 세 엔티티를 연결합니다. 예를 들어, "세션"의 "학생"은 "규율 등급"을 받았습니다.

o 4차 등

IDEF1X 방법론에서 참여 정도는 단항 또는 이진일 수 있습니다. 더 큰 정도의 연결은 이진 형식으로 축소됩니다.

IDEF1X 다이어그램의 연결 모양은 해당 연결의 힘, 유형 및 의무를 나타냅니다.

표 7.1. 관계 유형

모습 커뮤니케이션의 종류와 의무 링크 전원 오른쪽
1
필수, 식별 0 .. ∞

필수, 식별 0 또는 1

필수, 식별 1 .. ∞

<число>
필수, 식별 <число>
필수, 비식별 0 .. ∞
선택 사항, 비식별 0 .. ∞

메모.

1. 식별 링크는 실선으로 표시되고 비 식별 링크는 점선으로 표시됩니다.

2. 선택 사항은 다이아몬드로 표시됩니다.

다음 그림은 링크 매핑의 예를 보여줍니다.

a) 식별

b) 비식별

c) 재귀적

그림 7.3. 관계 예

무화과에. 7.3b에서 연결은 선택 사항입니다. 일부 직원은 부서(예: 기업 이사)의 일부일 필요가 없고 직원 번호가 각 직원마다 고유하기 때문에 식별할 수 없기 때문입니다.

4. 슈퍼클래스와 서브클래스의 정의.

두 개 이상의 엔터티가 속성 집합 측면에서 서로 약간 다른 경우 모델에서 구성을 사용할 수 있습니다. 즉, 슈퍼 클래스와 서브 클래스를 포함하는 상속 계층 구조(카테고리)입니다.

슈퍼 클래스 - 하위 클래스를 포함하는 엔터티.

상속 계층은 공유하는 엔터티의 특별한 유형의 그룹입니다. 일반적 특성. 예를 들어, 조직은 정규직 직원(정규직)과 시간제 직원을 고용합니다. 공통 속성에서 일반화된 엔터티(일반 조상) "Employee"(그림 7.4)를 구성하여 모든 유형의 직원에게 공통적인 정보를 나타낼 수 있습니다. 각 유형에 대한 특정 정보는 추가 엔터티(하위 항목) "정규직" 및 "시간제 근로자"에서 찾을 수 있습니다.


쌀. 7.4. 상속 계층(불완전한 범주)

일반적으로 상속 계층은 여러 엔터티에 공통된 의미의 속성이 있거나 엔터티가 의미에서 공통적인 관계를 가질 때 생성됩니다(예: "정규직"과 "시간제 근로자"가 의미에서 유사한 연결이 있는 경우) "조직" 엔터티와 "작업").

각 범주에 대해 다음을 지정해야 합니다. 판별자 - 한 개체를 다른 개체와 구별하는 방법을 보여주는 일반 조상의 속성입니다. 위의 예에서 판별자는 Type 속성입니다.


전체 카테고리 일반 조상의 한 인스턴스는 반드시 모든 후손의 인스턴스에 해당합니다. 즉, 이 예에서 직원은 반드시 시간제 직원, 컨설턴트 또는 정규 직원이어야 합니다.

모델을 만들 때 완전한 범주와 불완전한 범주의 다양한 조합이 가능합니다. 예를 들어 범주의 첫 번째 수준은 불완전하고 개별 엔터티는 두 번째 수준인 완전한 범주로 보완됩니다.

7.3. 개념도 작성의 예

다음 그림은 ERwin v9.2를 사용하여 구축된 허용 속도를 결정하는 작업에 대한 정보 모델의 개념 다이어그램의 일부를 보여줍니다.

쌀. 7.6. 정보 모델의 개념 체계의 단편

다음 논리적 데이터 블록은 개념 다이어그램에서 강조 표시됩니다.

참조 정보;

도로 구간에 대한 정보

계산 작업;

허용 속도 시트;

초안 주문 "H"(그림 7.6에는 표시되지 않음);

양식 번호 1, 1a 및 2(그림 7.6에는 표시되지 않음).

블록에 포함된 모든 엔티티("규제 및 참조 정보" 블록 제외)는 이름으로만 단편에 표시됩니다. "규제 및 참조 정보" 블록에 포함된 엔티티는 확장되어 표시됩니다. 모든 속성과 기본 키를 포함합니다. 이 블록에는 다른 요소와 연관되지 않은 두 개의 요소("곡선 결합에 대한 표준" 및 "곡선의 고도 기울기 기울기에 대한 허용 속도")가 있습니다. 데이터베이스 스키마는 연결된 그래프(모든 엔터티가 서로 연결되어야 함)여야 한다는 의견이 있기 때문에 이것은 실수가 아닙니다. 다양한 운영 정보가 데이터베이스에 축적되고 이를 기반으로 다양한 보고서와 요약이 구성되는 대부분의 작업에서 이러한 진술이 실제로 발생합니다. 그러나 엔지니어링, 최적화 및 기타 작업의 경우 관련 없는 테이블이 있을 수 있습니다. 이 예에서 두 개의 관련 없는 엔터티가 허용 속도의 각 계산에 참여합니다. 즉, 허용 속도 시트에 표시되는 결과에 영향을 줍니다. 그러나 문제의 세부 사항을 고려하여 이러한 표의 내용을 변경해도 이미 얻은 결과가 변경되어서는 안 됩니다. 따라서 테이블은 계산 작업이나 계산 결과와 연결되지 않습니다.